Re: [Xen-devel] Issue with PV superpage handling

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 25.06.12 at 18:07, Dave McCracken <dcm@xxxxxxxx> wrote:
> 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?

Debugging of certain code paths? Or discriminating certain
(unimportant) VMs?

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

Absolutely imo - not having done so from the beginning was
likely just an oversight (but that would need confirmation by
someone more familiar with that code than me).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel