Re: [Xen-devel] Pointed questions re Xen memory overcommit

[Tim Deegan <tim@xxxxxxx>]

At 12:53 -0800 on 24 Feb (1330088020), Dan Magenheimer wrote:
> 1) How is the capability and implementation similar or different
> from VMware's?  And specifically I'm asking for hard information
> relating to:
> 
> http://lwn.net/Articles/309155/ 
> http://lwn.net/Articles/330589/ 
> 
> I am not a lawyer and my employer forbids me from reading the
> related patent claims or speculating on any related issues, but
> I will be strongly recommending a thorough legal review before
> Oracle ships this code in any form that customers can enable.
> (I'm hoping for an answer that would render a review moot.)

I am not a lawyer and my employer forbids me from reading the
related patent claims or speculating on any related issues. :P

> 2) Assuming no legal issues, how is Xen memory overcommit different
> or better than VMware's, which is known to have lots of issues
> in the real world, such that few customers (outside of a handful
> of domains such as VDI) enable it?  Or is this effort largely to
> remove an item from the VMware sales team's differentiation list?
> And a comparison vs Hyper-V and KVM would be interesting also.

The blktap-based page-sharing tool doesn't use content hashes to find
pages to share; it relies on storage-layer knowledge to detect disk
reads that will have identical results.  Grzegorz's PhD dissertation and
the paper on Satori discuss why that's a better idea than trying to find
shareable pages by scanning.

I agree that using page sharing to try to recover memory for higher VM
density is, let's say, challenging.  But in certain specific workloads
(e.g. snowflock &c), or if you're doing something else with the
recovered memory (e.g. tmem?) then it makes more sense.

I have no direct experience of real-world deployments.

> 3) Is there new evidence that a host-based-policy-driven memory
> balancer works sufficiently well on one system, or for
> multiple hosts, or for a data center? 

That, I think, is an open research question.

> It would be nice for
> all Xen developers/vendors to understand the intended customer
> (e.g. is it the desktop user running a handful of VMs running
> known workloads?)

With my hypervisor hat on, we've tried to make a sensible interface
where all the policy-related decisions that this question would apply to
can be made in the tools.  (I realise that I'm totally punting on the
question).

> Perhaps this would be a better topic for the Xen Hack-a-thon...
> sadly I won't be there and, anyway, I don't know if there will
> be a quorum present of the Xen developers specifically working
> on memory overcommit technology, so I thought it should be
> brought up on-list beforehand.

I won't be at the hackathon either.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel