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. > -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
