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

[Juergen Gross <jgross@xxxxxxxx>]

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. Or we could do that on x86, too.
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.

I'm open for all possibilities mentioned above.


Juergen

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