Hi Serge, On 04/10/2015 02:43 AM, Serge E. Hallyn wrote: > On Mon, Apr 06, 2015 at 01:47:35PM -0400, Tejun Heo wrote: >> Hello, Preeti. >> >> On Thu, Apr 02, 2015 at 12:26:32PM +0530, Preeti U Murthy wrote: >>> 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? >> >> The problem is not really about which behavior is "righter" but rather >> it's fairly likely that there are users / tools out there expecting >> the current behavior and they wouldn't be too happy to see the >> behavior flipping underneath them. >> >> One way forward would be implementing a knob in cpuset which makes it >> switch sbetween the old and new behaviors in the legacy hierarchy. >> It's yucky but doable if absoluately necessary, but what's the reason >> for you not being able to transition to the unified hierarchy (except > > If the userspace is entirely new then this should work. The > unified hierarchy's behavior is not backward-compatible so any old > software which tried to create cgroups (libcgroup, lxc, etc) will > not work with it (since it won't, for instance, know to fill in > the enabled controllers in every newly created cgroup). > > Preeti, can you confirm that you don't have any need to run any > legacy programs which use cgroups? Long as that's the case, new I don't think I can vouch for this safely. I have posted out a V2 of this patch adhering to Tejun's first suggestion. IMO that seemed like a better option. Regards Preeti U Murthy -- 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
