[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 it. 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. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |