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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan


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