Re: [Xen-devel] [PATCH 0/5] xen: better grant v2 support

[Juergen Gross <jgross@xxxxxxxx>]

On 23/08/17 10:36, Jan Beulich wrote:
>>>> On 23.08.17 at 09:49, <jgross@xxxxxxxx> wrote:
>> On 22/08/17 14:48, Jan Beulich wrote:
>>>>>> On 21.08.17 at 20:05, <jgross@xxxxxxxx> wrote:
>>>> Currently Linux has no support for grant v2 as this would reduce the
>>>> maximum number of active grants by a factor of 2 compared to v1,
>>>> because the number of possible grants are limited by the allowed number
>>>> of grant frames and grant entries of v2 need twice as much bytes as
>>>> those of v1.
>>>>
>>>> Unfortunately grant v2 is the only way to support either guests with
>>>> more than 16TB memory size or PV guests with memory above the 16TB
>>>> border, as grant v1 limits the frame number to be 32 bits wide.
>>>>
>>>> In order to remove the disadvantage of grant v2 this patch series
>>>> enables configuring different maximum grant frame numbers for v1 and
>>>> v2.
>>>
>>> But that does imply higher memory footprint of such a guest in Xen,
>>> doesn't it?
>>
>> With current defaults this would need up to 128kB more for a guest using
>> v2 grants.
> 
> At least in an auto-ballooned setup this may make the difference
> between a guest being able or failing to start.
> 
>>> The limit, after all, is there to bound resource use of
>>> DomU-s.  I wonder whether we shouldn't make any such increase
>>> dependent on first putting in place proper accounting of the memory
>>> used for individual domains.
>>
>> So you would want to have a way to count pages (or bytes?) allocated for
>> hypervisor internal needs on a per-domain basis, right?
>>
>> Would that be additional to struct domain -> xenheap_pages or would you
>> want to merge the new counter into it? I guess a new field would be
>> required in order to avoid counting some data twice.
>>
>> Do you have an idea what to do with that value? Do you want to expose it
>> to the user (dom0 admin), or should it be used just inside the
>> hypervisor and e.g. printed by a debug key handler?
>>
>> Do you want an additional set of allocating functions doing the
>> accounting, or should the existing functions be used with an additional
>> domain pointer, or should the caller be responsible doing the additional
>> accounting?
>>
>> Do you want an all-or-nothing approach or a gradual move to add the new
>> accounting step by step?
> 
> We've been vaguely discussing this in the past on a few occasions.
> My personal thinking is that the "memory=" setting in a guest config
> really ought to express all the memory associated with a guest. But
> of course there'll be problems with us starting to do so, and that's
> beyond people observing less memory in their guests. Switching to
> such a full accounting model will require some careful thought (and
> discussion up front). Hence I've only said "I wonder whether", i.e.
> I don't mean to make this a strict prerequisite to the proposed
> changes here. I'd be in particular interested to hear opinions of a
> few other people.

Fair enough.

Just some thoughts on that topic from my side:

This approach should be fine IMO for memory allocated while creating a
domain. This is basically the same as a bare metal system where the BIOS
needs some memory.

Memory allocated during the lifetime of a domain is a different problem:
either you allow the domain to claim more memory as configured, or you
have to reserve a more or less arbitrary amount of memory to be
allocated later and eventually fail such allocations. I don't think this
approach is acceptable.


Juergen

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