[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC 1/2] xen/mm: Clarify the granularity for each Frame Number

>>> On 12.08.15 at 14:57, <julien.grall@xxxxxxxxxx> wrote:
> On 12/08/15 12:58, Jan Beulich wrote:
>>>>> On 12.08.15 at 13:13, <julien.grall@xxxxxxxxxx> wrote:
>>> On 12/08/15 11:33, Jan Beulich wrote:
>>>>>>> On 12.08.15 at 11:57, <julien.grall@xxxxxxxxxx> wrote:
>>>>> On 12/08/2015 08:16, Jan Beulich wrote:
>>>>>>>>> On 05.08.15 at 15:18, <julien.grall@xxxxxxxxxx> wrote:
>>>>>>> When the backend is 64K, it will map the foreign 4K at the top of a 64K
>>>>>>> page. It's a waste of memory, but it's easier to implement and it's
>>>>>>> still and improvement compare to have Linux crashing at boot.
>>>>>> Waste of memory? You're only mapping an existing chunk of memory.
>>>>>> DYM waste of address space?
>>>>> No, I really meant waste of memory. The current grant API in Linux is 
>>>>> allocating one Linux Page per grant. Although the grant is always 4K, so 
>>>>> we won't be able to make use of the 60K for anything as long as we use 
>>>>> this page for a grant.
>>>>> So if the grant is pre-allocated (such as for PV block), we won't be 
>>>>> able use nr_grant * 60KB memory.
>>>> I still don't follow - grant mappings ought to be done into ballooned
>>>> (i.e. empty) pages, i.e. no memory would get wasted unless there
>>>> are too few balloon pages available.
>>> Everything balloon out is less memory that can be used by Linux. If we
>>> are only using 1/15 of the balloon out page that a huge waste of memory
>>> for me.
>> I still don't get it: A ballooned page does not represent any memory
>> (and at least on x86 iirc we start PV domains with 8Mb sort-of-
>> pre-ballooned space). Where is the loss you're talking about coming
>> from? Or, wait - you don't have PoD (yet) on ARM, so you have no
>> choice.
> I'm not sure how PoD would affect the problem here...

You would have a way to start a guest with some unpopulated
space set aside, i.e. instead of ballooning out memory it could
use unpopulated pages to map the grants into.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.