Re: [Xen-devel] [PATCH RFC] Remove PV superpage support (v1).

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 01.02.16 at 09:03, <JGross@xxxxxxxx> wrote:
> On 01/02/16 08:53, Jan Beulich wrote:
>>>>> On 01.02.16 at 05:54, <JGross@xxxxxxxx> wrote:
>>> On 29/01/16 17:46, Jan Beulich wrote:
>>>>>>> On 29.01.16 at 17:26, <konrad.wilk@xxxxxxxxxx> wrote:
>>>>> On Fri, Jan 29, 2016 at 09:00:15AM -0700, Jan Beulich wrote:
>>>>>>>>> On 29.01.16 at 16:30, <konrad.wilk@xxxxxxxxxx> wrote:
>>>>>>> I am hoping the maintainers can guide me in how they would like:
>>>>>>>  - Deal with documentation? I removed the allowsuperpage from 
>>>>>>> documentation
>>>>>>>    but perhaps it should just mention deprecated?
>>>>>>
>>>>>> Since you delete the option, deleting it from doc seems fine to me.
>>>>>>
>>>>>>>  - I left put_superpage as put_page_from_l2e calls it - but I can't see
>>>>>>>    how the _PAGE_PSE bit would be set as you won't be able to even
>>>>>>>    put that bit on (after my patch). Perhaps just make it an
>>>>>>>    ASSERT in put_page_from_l2e?
>>>>>>
>>>>>> No, that can't be done. Did you check why it is the way it is
>>>>>> (having to do with the alternative initial P2M placement, which
>>>>>> does use superpages despite the guest itself not being able to
>>>>>> create any)?
>>>>>
>>>>> If I recall - this was done for P2M array when put in a different virtual
>>>>> address space? And this being only the initial domain - would this ..
>>>>> Oh this can be done for normal guests as well I presume?
>>>>
>>>> Iirc JÃrgen enabled this for DomU too not so long ago.
>>>
>>> I did. The Xen tools won't use superpages for the p2m array, however.
>> 
>> That's unfortunate. Is there a reason for this?
> 
> It's a matter of complexity. Adding superpage usage for the p2m array
> would add quite some code to the tools without a real gain, as the domU
> will have to split the superpage in any case in order to be able to
> support migration of the domain. So the only gain would be to save
> about 0.2% of memory footprint while booting the kernel (when the kernel
> is up the difference would be zero).

Okay, makes sense. I just assumed that like in the Dom0 case
the code to set up the table would have been new anyway (due
to which in the Dom0 case it was actually natural to use large
pages where possible).

Jan

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