On 3/5/08 14:53, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> wrote:
>> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
>> Okay, I will comment when I see it. I'm not sure what design you are working
>> on: perhaps extract memory stats from the guest via xenbus and implement
>> ballooning policy in dom0? That is what I would prefer to see. The Novell
>> ballooning-limit checks were only added as a safety backstop in the guest
>> itself. Apart from tweaking it to make it less conservative where we are
>> confident that is safe, any more complicated policy, and of course and
>> cross-domain global optimisation, doesn't belong in the
>> individual guests.
>
> (cc's removed due to topic drift)
>
> 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.
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|