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

[Juergen Gross <jgross@suse.com>]

On 01/02/16 08:53, Jan Beulich wrote:
>>>> On 01.02.16 at 05:54, <JGross@suse.com> wrote:
>> On 29/01/16 17:46, Jan Beulich wrote:
>>>>>> On 29.01.16 at 17:26, <konrad.wilk@oracle.com> wrote:
>>>> On Fri, Jan 29, 2016 at 09:00:15AM -0700, Jan Beulich wrote:
>>>>>>>> On 29.01.16 at 16:30, <konrad.wilk@oracle.com> 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).

Juergen

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