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

RE: [Xen-devel] [PATCH] linux/balloon: don't allow ballooningdowna domain below a reasonable limit



> > I was planning on providing both Model C and Model D (see below),
> > but let me know if you will only accept Model C (or even Model B)
> > and I will adjust accordingly.
> 
> I don't know that what you are trying to do is, in full generality,
> tractable. Who knows how valuable the memory pages belonging 
> to a domU are,
> relative to other domains? Just because they are only 
> buffer-cache pages,
> for example, may not necessarily mean we want the domU to 
> aggressively page
> them out every N seconds.
>
> At least if you can extract some measure of memory pressure 
> from each domU
> (e.g., paging frequency, size of active/inactive page lists) 
> dom0 can then
> make some global optimisation periodically based on e.g., relative
> priorities of domains.
> 
> Not that your approach is not applicable for some scenarios. 
> As long as it's
> a switchable option, perhaps it is the kind of thing to let 
> users vote on.

I agree the general case is not tractable.  But I think the
basic concept is useful and an initial implementation may
serve as a good foundation for later tuning.  The initial
selfballooning policy is simply "if I have extra memory,
give it up; and if I need memory, ask for it back"; where
"extra" and "need" are admittedly poorly estimated (but are
good enough for some workloads) and the grant-memory-to-
asking-domain policy is first-come-first-served.  Any
more complex policy certainly requires more information
to be passed from the guest to domain0.

OK, I will submit a patch to cover both Model C and D.
Still tracking down a bug or two...

Dan



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


 


Rackspace

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