Re: [Xen-devel] [PATCH v8 13/15] xen: make grant resource limits per domain

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.09.17 at 10:44, <jgross@xxxxxxxx> wrote:
> On 22/09/17 10:35, Jan Beulich wrote:
>>>>> On 22.09.17 at 10:27, <jgross@xxxxxxxx> wrote:
>>> On 22/09/17 09:53, Jan Beulich wrote:
>>>>>>> On 22.09.17 at 08:19, <jgross@xxxxxxxx> wrote:
>>>>> On 21/09/17 13:48, Jan Beulich wrote:
>>>>>>>>> On 21.09.17 at 13:39, <jgross@xxxxxxxx> wrote:
>>>>>>> On 21/09/17 13:31, Jan Beulich wrote:
>>>>>>>>>>> On 21.09.17 at 09:53, <jgross@xxxxxxxx> wrote:
>>>>>>>>> On 21/09/17 08:15, Jan Beulich wrote:
>>>>>>>>>>>>> On 21.09.17 at 06:35, <jgross@xxxxxxxx> wrote:
>>>>>>>>>>> On 20/09/17 17:35, Jan Beulich wrote:
>>>>>>>>>>>>>>> On 20.09.17 at 14:44, <jgross@xxxxxxxx> wrote:
>>>>>>>>>>>>> On 20/09/17 13:48, Jan Beulich wrote:
>>>>>>>>>>>>>>>>> On 20.09.17 at 13:10, <jgross@xxxxxxxx> wrote:
>>>>>>>>>>>>>>> I thought about a cap and TBH I'm not sure which would be sane 
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> apply. The global limits seem wrong, especially looking at 
>>>>>>>>>>>>>>> patch 14:
>>>>>>>>>>>>>>> those limits will be for dom0 only then. And dom0 won't need 
>>>>>>>>>>>>>>> many
>>>>>>>>>>>>>>> grant frames in the normal case...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've been thinking about this Dom0 aspect too over lunch. What
>>>>>>>>>>>>>> about allowing the hardware domain to set its limit (only upwards
>>>>>>>>>>>>>> of course) in setup_table(), without any upper bound enforced?
>>>>>>>>>>>>>> This would free up the globals to be used as system wide limits
>>>>>>>>>>>>>> again.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This would be possible, of course.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The question is whether the need to re-allocate the frame pointer 
>>>>>>>>>>>>> arrays
>>>>>>>>>>>>> is it worth.
>>>>>>>>>>>>
>>>>>>>>>>>> Input by others would be helpful...
>>>>>>>>>>>
>>>>>>>>>>> I think I'll go with additional cap boot parameters, so I don't 
>>>>>>>>>>> think
>>>>>>>>>>> we need dom0 to modify its own limits.
>>>>>>>>>>
>>>>>>>>>> So are we in agreement then that no new command line options
>>>>>>>>>> are needed, and that hence the cap will be applicable to all
>>>>>>>>>> domains (with Dom0 simply not having any other limit enforced
>>>>>>>>>> on it)?
>>>>>>>>>
>>>>>>>>> Hmm, I meant this to be the other way round: having distinct 
>>>>>>>>> parameters
>>>>>>>>> for dom0 and the cap.
>>>>>>>>>
>>>>>>>>> In case you like it much better to merge them I won't argue over it.
>>>>>>>>
>>>>>>>> Well, late yesterday evening it occurred to me that it would
>>>>>>>> only be consistent to apply the same cap to all domains. That's
>>>>>>>> in particular to not penalize a non-Dom0 hardware domain in
>>>>>>>> comparison with Dom0 itself.
>>>>>>>
>>>>>>> That's correct.
>>>>>>>
>>>>>>> OTOH e.g. a cap of lets say 1024 grant frames but Dom0 configured to
>>>>>>> 4 only (why would it need more?) would make sense: the grant frame array
>>>>>>> for Dom0 would need 32 bytes only instead of the 8kB for the 1024 frames
>>>>>>> if the cap would be the configuration value for Dom0.
>>>>>>
>>>>>> May I suggest that for now we use the simpler variant without
>>>>>> extra Dom0 command line options, and later (post 4.10), if you or
>>>>>> anyone else really feels like it, Dom0 specific options be introduced?
>>>>>
>>>>> While applying these changes to my series I realized this might be a bad
>>>>> choice for ARM: the dom0 grant table is here limited to about 100 pages.
>>>>> If there is some need to have a domU with more grant frames the system
>>>>> wouldn't be able to boot as the high cap would be used for the dom0
>>>>> grant frame number.
>>>>
>>>> Why can't ARM code lower the Dom0 values without lowering the
>>>> caps?
>>>
>>> So either we let control the max_grant_frames value the cap _and_ the
>>> dom0 value or not. We could handle this differently on ARM, of course,
>>> but this would mean that the dom0 value on ARM wouldn't be adjustable
>>> other than as a compile time option.
>> 
>> Why? If the specified value is lower than the about 100 pages
>> allow for, it could still take effect.
> 
> So you would like to use the lower value of max_grant_frames and the
> maximum possible value on ARM for dom0?
> 
> Doesn't seem to be the worst option: instead of refusing to boot like
> today in case someone entered a value too high it would just use a
> sane value.

Indeed.

>>> Or we could do that on x86, too.
>> 
>> Not without an actual need to, I would say.
>> 
>>> For setting a compile time value of dom0 I'd go with a rather low value
>>> like INITIAL_NR_GRANT_FRAMES.
>>>
>>> In the end having a sub-option for dom0 isn't that complicated, IMO.
>> 
>> That's true, but the inflation of command line options is by itself
>> worrying to me.
> 
> Okay.
> 
> BTW: would you mind me making the cap values modifiable at runtime? I
> think this could be a nice feature requiring just to use
> integer_runtime_param() instead of integer_param().

That's a good idea - go for it.

Jan

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