Re: Issue with PV superpage handling

[Dave McCracken <dcm@mccr.org>]

On Monday, June 25, 2012, Jan Beulich wrote:
> > My question is, what is the value of enforcing all-or-nothing for PV 
> > guests?  Is it the case that PV guests have to be entirely in either one 
> > mode or the other?
> 
> Since I understand a PV guest's balloon driver must play with
> this, I indeed think this is a strictly separated set.

I specifically need to be able to guarantee superpage-backed memory in PV 
guests to be able to map them as superpages (hugepages in Linux).  I'm trying 
to come up with some benefit for opportunistic superpages in PV guests, but 
nothing comes to mind.

> > I'm not particularly fussed about having a way to disable the 
> > opportunistic superpage allocation for HVM guests, and just turning that 
> > on all the time.  I only really used the flag because I saw it was being 
> > passed but wasn't being used; I didn't realize it was meant to have the 
> > "use superpages or abort" semantics.  My only non-negotiable is that we 
> > have a way to get opportunistic superpages for HVM guests.
> 
> Couldn't we have the setting be an override for the HVM
> allocation behavior (defaulting to enabled there), and have
> the originally intended meaning for PV (disabled by default)?

I like this idea.  It would be simple enough.

Is there any reason to allow disabling HVM superpage allocation?  HVM domain 
creation always allocates as many superpages as it can, then falls back to 
small pages for the rest.  Wouldn't it be reasonable to make restore always do 
this too?

Dave McCracken
Oracle Corp.