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