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

NP. I just wanted to point it out.


Xen-devel mailing list



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