[lkml]   [2015]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] cpusets: Make cpus_allowed and mems_allowed masks hotplug invariant
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.

Preeti U Murthy

 \ /
  Last update: 2015-04-10 16:41    [W:0.077 / U:1.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site