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

[Olaf Hering <olaf@xxxxxxxxx>]

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.

> 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?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel