Hi,
At 13:47 +0000 on 09 Mar (1299678468), George Dunlap wrote:
> It occured to me, it might be simpler if we check for a zero superpage
> when doing a decrease_reservation call instead. We'd only do a sweep
> if the p2m entry is currently a superpage. If that's the case, we
> sweep the superpage containing that mfn and nothing else. If the
> whole superpage isn't zero, we'll shatter the superpage in the p2m
> tables, so that even if we get an mfn from the same page again, we
> won't scan it.
Do you think ballooned-out pages are likely to be in 2MB chunks of
zeroed memory? Apart from avoiding shattering and re-gathering a 2MB
p2m range (which is nice, but proabbly not the perf bottleneck for PoD
right now), this is a change from scanning arbitrary memory when we run
out to scanning memory around balloon sites as we go.
If this is likely to have a high hit rate, great. If not, it might be
(overall) worse because we waste time scanning as we balloon and have to
do the full scan later anyway.
> I was going to say, "scan only if the number of p2m entries is higher
> than the number of entries in the cache". But it occurred to me, it
> might not be a bad idea to scan for zero pages in any case -- so that
> we can consolidate even after the guest has been running for a while.
I'm not so keen on that - AFAICS once we've passed #pod-entries ==
#pod-pages, we shouldn't be doing any expensive work for PoD. We might
want to think about defragging HVM guests independently of the PoD
stuff, though.
Cheers,
Tim.
--
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home