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

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

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


Xen-devel mailing list



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