[Xen-devel] Re: RFC: Doing a superpage zero-sweep on decrease_reservation

[Tim Deegan <Tim.Deegan@xxxxxxxxxx>]

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