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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 25.06.12 at 17:08, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
> On 25/06/12 15:38, Dave McCracken wrote:
>> Awhile back I added the domain config flag "superpages" to support Linux
>> hugepages in PV domains.  When the flag is set, the PV domain is populated
>> entirely with superpages.  If not enough superpage-sized chunks can be found,
>> the domain creation fails.
>>
>> At some time after my patch was accepted, the code I added to domain restore
>> was removed because I broke page allocation batching.  I put it on my TODO
>> list to reimplement it, then it got lost, for which I apologize.
>>
>> Now I have gotten back to reimplementing PV superpage support in restore, I
>> find that recently other code was added to restore that, while triggered by
>> the superpage flag, only allocates superpages opportunistically and falls 
> back
>> to small pages if it fails.  This breaks the original semantics of the flag
>> and could cause any OS that depends on the semantics to fail 
> catastrophically.
>>
>> I have a patch that implements the original semantics of the superpage flag
>> while preserving the batch allocation behavior.  I can remove the competing
>> code and submit mine, but I have a question.  What value is there in
>> implementing opportunistic allocation of superpages for a PV (or an HVM)
>> domain in restore?  It clearly can't be based on the superpages flag.
>> Opportunistic superpage allocation is already the default behavior for HVM
>> domain creation.  Should it also be a default on HVM restore?  What about 
> for
>> PV domains?  Is there any real benefit?
> Well the value of having superpages for HVM guests is pretty obvious.  
> When using hardware assisted pagetables (HAP), the number of memory 
> reads on a TLB lookup is guest_levels * p2m_level -- so on a 64-bit 
> guest, the one extra level of p2m could cause up to 4 extra memory reads 
> for every TLB miss.  The reason to do it opportunistically instead of 
> all-or-nothing is that there's no reason not to -- every little helps. :-)
> 
> 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'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)?

Jan


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