[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 4 of 4] xenpaging: initial libxl support

On Thu, 2012-01-12 at 14:12 +0000, Olaf Hering wrote:
> On Wed, Jan 11, Tim Deegan wrote:
> > At 17:38 +0100 on 11 Jan (1326303483), Olaf Hering wrote:
> > > On Wed, Jan 11, Tim Deegan wrote:
> > > 
> > > > > Isnt that up to the host admin to decide where to take the memory 
> > > > > from?
> > > > > So if its acceptable to swap parts of a VM (independent from what the
> > > > > guest OS thinks it has), so be it.
> > > > 
> > > > Why?  The _only_ reason I can imagine for wanting to use paging is when
> > > > the balloon driver can't or won't do its job.  There's no advantage to
> > > > paging except that you can always force it to happen.
> > > 
> > > Isnt that the whole point of paging, to make it happen at will without
> > > the guest (or the application at process level) noticing it?
> > 
> > Yes, but that's a _bad_ thing. :)  If the guest can co-operate, you'll
> > get way better eviction choices, better performance, and better
> > accounting (since the I/O is done by the guest to guest-owned disk).
> Hmm, I think its slightly like an 'rm -rf *' accident: bad, but allowed.

You analogy is bogus, the "support" for "rm -rf *" comes legitimately
(even if unfortunately) from the combined semantics of the shell and rm
and just falls out from the normal use cases.

In the case of paging we would have to add explicit support for doing
something which we think has no purpose. I think it is OK for libxl to
offer the flexibility to toolstack authors to do this however they want
but xl should only expose a single "target" value.

> > That's why I think both mechanisms should be visible up to the libxl
> > layer, but xl itself should just implement the one sensible policy:
> > try ballooning first, then page if that fails.  
> So you are saying xl should take care of an improved mem-set command?
> Perhaps by tweaking memory/target first, monitoring something like
> tot_pages, and if memory/target isnt reached after some time, tweak
> memory/target-tot_pages so that xenpaging takes care of the rest?

Yes, although there is no need for monitoring, it can just be set
memory/target, wait, set memory/target-tot_pages. If the balloon driver
has caught up then setting target-tot_pages will be a nop but it still
correctly reflects the desired state of the system and so we should set

Another alternative would be for the pager to add some hysteresis after
it observes a change in the target before it starts "implementing" it.
This would allow the toolstack to just set things one shot. I'm not sure
that this is better though -- it makes things a little less flexible for
the toolstack and encodes policy in the pager. 


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.