Re: [PATCH V2] cpuset: Add knob to make allowed masks hotplug invariant on legacy hierarchy

From: Preeti U Murthy
Date: Wed Apr 15 2015 - 07:41:14 EST


On 04/13/2015 08:13 PM, Peter Zijlstra wrote:
> On Mon, Apr 13, 2015 at 05:46:37PM +0530, Preeti U Murthy wrote:
>> On 04/13/2015 12:31 PM, Peter Zijlstra wrote:
>
>>> Would it not make sense to make that a mount option and limit the amount
>>> of semantic variants of cpusets?
>>
>> I spent some time analyzing if this would be a better option than the
>> sysfs knob and I think not for the following reasons:
>>
>> 1. Mount options tend to be generic across the controllers of a cgroup.
>> But use case addressed by this patch is specific to the cpuset controller.
>
> Surely we can get around that somehow.
>
>> 2. The behavior that this patch is trying to bring about is not a
>> drastic one to call for a mount option equivalent to the __SANE_BEHAVIOR
>> one that existed earlier. This option was used to switch the legacy
>> design to the default one.
>>
>> However this patch is not *wholly* mimicking the default hierarchy
>> behavior. The behavior when cpusets become empty is left untouched for
>> instance. The patch borrows one of the behaviors from the default
>> hierarchy only and hence just not justify the use of a mount flag.
>
> So the 'problem' I have is that you introduce a 3rd semantic for the
> cpuset thing.
>
> You also do not answer if you can live with the default hierarchy
> behaviour, only that your patch mimicks a subset of it.
>
> Why not all of it?

This was assuming that the existing software will break if we mimick the
entire design given that we were informed that it does not work well
with the default hierarchy. But I think now, that its worth finding out
why if so and switch over to the new design, atleast for cpusets.

Regards
Preeti U Murthy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/