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

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



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

Jan


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

 


Rackspace

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