Date: Wed, 15 Apr 2015 10:03:02 -0500
From: "Serge E. Hallyn" <serge@hallyn.com>
To: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>, tj@kernel.org,
        svaidy@linux.vnet.ibm.com, nacc@linux.vnet.ibm.com, rjw@rjwysocki.net,
        linux-kernel@vger.kernel.org, lizefan@huawei.com, anton@samba.org,
        bharata@linux.vnet.ibm.com, cgroups@vger.kernel.org,
        paulmck@linux.vnet.ibm.com, mingo@kernel.org, serge@hallyn.com
Subject: Re: [PATCH V2] cpuset: Add knob to make allowed masks hotplug
 invariant on legacy hierarchy
Message-ID: <20150415150302.GA25089@mail.hallyn.com>
References: <20150410141118.11284.36206.stgit@preeti.in.ibm.com>
 <20150411083537.GR27490@worktop.programming.kicks-ass.net>
 <20150413070117.GX24151@twins.programming.kicks-ass.net>
 <552BB3A5.9060905@linux.vnet.ibm.com>
 <20150413144311.GF5029@twins.programming.kicks-ass.net>
 <552E4E41.3030008@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <552E4E41.3030008@linux.vnet.ibm.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2138
Lines: 46

On Wed, Apr 15, 2015 at 05:10:49PM +0530, Preeti U Murthy wrote:
> 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.

Peter, is the question "why can't we just use the unified hierarchy for
cpusets"?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/