[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1378956606.5517.35.camel@marge.simpson.net>
Date: Thu, 12 Sep 2013 05:30:06 +0200
From: Mike Galbraith <bitbucket@...ine.de>
To: Frederic Weisbecker <fweisbec@...il.com>
Cc: Christoph Lameter <cl@...ux.com>,
Gilad Ben-Yossef <gilad@...yossef.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Mike Frysinger <vapier@...too.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [RFC] Restrict kernel spawning of threads to a specified set of
cpus.
On Wed, 2013-09-11 at 23:36 +0200, Frederic Weisbecker wrote:
> On Wed, Sep 11, 2013 at 02:21:06PM +0000, Christoph Lameter wrote:
> > On Wed, 11 Sep 2013, Mike Galbraith wrote:
> >
> > > Mind saying why? To me, creating properties of exclusive sets of CPUs
> > > that the interface which manages sets and their properties is not fully
> > > aware of is a dainbramaged thing to do.
> >
> > cpusets is being replaced by cgropus.
>
> You are confusing me. Cpusets is a cgroups subsystem, how can it be replaced
> by it?
Yeah, the only irritant I know of is the cpuset API variability. It has
a backward compatibility mount option, so anything other than the user
mounting makes the API selection decision for him/her. systemd mounts
cpuset, i.e. OS component pokes OS API backward compatibility button,
breaking OS API backward compatibility for the user, who then has to
squabble with OS component over button possession if he wants his old
cpuset API using toys to continue to work.
-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists