Re: [Xen-devel] [PATCH v5 3/8] xen: delay allocation of grant table sub structures

[Juergen Gross <jgross@xxxxxxxx>]

On 11/09/17 13:02, Jan Beulich wrote:
>>>> On 11.09.17 at 11:39, <jgross@xxxxxxxx> wrote:
>> On 11/09/17 11:23, Jan Beulich wrote:
>>>>>> On 11.09.17 at 11:03, <jgross@xxxxxxxx> wrote:
>>>> On 08/09/17 17:28, Jan Beulich wrote:
>>>>>>>> On 08.09.17 at 08:56, <jgross@xxxxxxxx> wrote:
>>>>> And if you special case Dom0,
>>>>> wouldn't it be better to (also) special case the hardware domain
>>>>> (in case that's not Dom0)?
>>>>
>>>> As a hardware domain not being dom0 would need to be created via the
>>>> appropriate domctl hypercalls I don't see why the measures for all
>>>> other domains wouldn't be enough for that case.
>>>
>>> Yes, that's true especially when making the domctl mandatory to be
>>> used. Whether suitable default values for that case wouldn't better
>>> live in a single place (the hypervisor) is a point to be considered
>>> here, though (by default values I mean ones to be used when the
>>> config file doesn't specify any, not ones to be used by the domctl
>>> handler if the passed in values are zero or some other "use
>>> defaults" indicator, as you had elsewhere).
>>
>> But this is exactly what happens: the hypervisor defaults are being
>> used in case nothing is specified in the domain's config file: a value
>> of 0 for a value (grant table frame limit or maptrack frame limit)
>> specified in the domctl will just use the default values.
>>
>> Or did I misunderstand you here?
> 
> Hypervisor defaults are in general meaningless when the domctl
> becomes mandatory (as indicated elsewhere, at least for the
> maptrack table size I view zero as a valid to use option). The only
> time hypervisor defaults would continue to be needed would be
> for Dom0 and, maybe (for consistency as explained) for the
> hardware and/or control domains.
> 
>>>> Just to be sure I understand you correctly: you want to get rid of
>>>> INITIAL_NR_GRANT_FRAMES and just grow from 0 on instead of starting at
>>>> the current value 4, right?
>>>
>>> Yes, the use of INITIAL_NR_GRANT_FRAMES would move to that
>>> first "grow" invocation.
>>
>> Hmm, shouldn't we just grow one frame after the other? Is it really true
>> that most domains will need more than 1500 grants? A simple test domain
>> with one disk and one NIC seems to be okay with a little bit more than
>> 300 grants, so 1 grant table frame would be enough for that case.
> 
> Yes and no. Yes because indeed many domains will not need more.
> No, however, because of the risk of memory shortage: By giving all
> domains a certain minimum, they can prepare themselves for how
> much (or really how little) they can do without depending on there
> being memory available to grow the tables later on. IOW I don't
> generally object to the limit being reduced, but not as a side effect
> of the re-work. In case of problems this needs to be easy to revert
> (or adjust). I.e. the change can be in the same series, but ought to
> be a separate patch.

Okay, I'll add another patch for that purpose.


Juergen

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