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

[Juergen Gross <jgross@xxxxxxxx>]

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.

And for being able to cover the xl defaults of the grant frame limits of
huge hosts I need to set the cap to at least 64 now. I'd like to raise
it even more, lets say to 256 or 512, in order to have some headroom.

So I think I'm going with the dom0 sub-option for the max_grant_frames
parameter. I don't think it is needed for max_maptrack_frames, as dom0
will be normally the domain needing the highest value.


Juergen

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