Re: [PATCH] cpusets: Make cpus_allowed and mems_allowed masks hotplug invariant

[Preeti U Murthy <preeti-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>]

Hi Tejun, Peter,

On 10/09/2014 06:36 PM, Tejun Heo wrote:
> On Thu, Oct 09, 2014 at 01:50:52PM +0530, Preeti U Murthy wrote:
>> However what remains to be answered is that the V2 of cgroup design -
>> the default hierarchy, tracks hotplug operations for children cgroups as
>> well. Tejun, Li, will not the concerns that Peter raised above hold for
>> the default hierarchy as well?
> 
> I don't think the legacy one is a good design.  Kernel shouldn't lose
> configurations in an irreversible way and the legacy one is also
> making random cpuset flips by migrating tasks upwards anyway.  In
> terms of hotunplug behavior, the legacy and unified ones behave the
> same.  The only difference is that the configuration is independent of
> the current state and the configured behavior is restored when the
> cpus come back.  The other side is that the legacy hierarchy behavior
> simply can't be allowed when the hierarchy is shared among multiple
> controllers as in the unified hierarchy.  It affects all other
> controllers attached to the hierarchy.

We have a use case currently, which needs this to be fixed one way or
the other. While running in a virtualized setup, there may be a need to
hotplug in resources to VMs at runtime. This includes CPUs and Memory.
Due to the behavior of the legacy hierarchy, the new CPUs never get
used. This is not even a scenario where we hot-unplugged CPUs and ask
for it to be plugged back again. Its a case where the workloads running
within a VM are in need of more resources than they began with.

> 
> That said, we can't change the behavior on the legacy one.  It's a
> very userland visible behavior.  We simply can't change it, so

By ensuring that the user configured cpusets are untouched, I don't see
how we affect userspace adversely. The expectation usually is that the
kernel keeps track of the user configurations. If anything we would be
fixing an undesired behavior, wouldn't we?

> unfortunately you're stuck with it at least on the legacy hierarchy.

Given that we are in much need for this to be fixed and that we cannot
easily move to the default hierarchy, can you please take a look at this
patch again?

It is understandable that there are good reasons why legacy hierarchy
currently behaves this way or how we cannot drastically change its
behavior, but there is no sane way in which userspace can get around
this for the sake of genuine use cases such as the above.

Regards
Preeti U Murthy
> 
> Thanks.
>