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

[Juergen Gross <jgross@xxxxxxxx>]

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.

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


Juergen

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