Message-ID: <1378911206.5476.134.camel@marge.simpson.net>
Subject: Re: [RFC] Restrict kernel spawning of threads to a specified set of
 cpus.
From: Mike Galbraith <bitbucket@online.de>
To: Christoph Lameter <cl@linux.com>
Cc: Gilad Ben-Yossef <gilad@benyossef.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Frederic Weisbecker <fweisbec@gmail.com>,
        Mike Frysinger <vapier@gentoo.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Date: Wed, 11 Sep 2013 16:53:26 +0200
In-Reply-To: <000001410d659f85-21128fa5-a252-4006-804c-4ff03acbd50f-000000@email.amazonses.com>
References: <00000140efbcb701-c26320b3-f434-4538-bc80-8e92fed6f303-000000@email.amazonses.com>
	 <CAOtvUMe=jcAHXNJU_rTAAokaE4KZNUTFsHVVTTxgFW_xj8ONxg@mail.gmail.com>
	 <1378795659.6046.41.camel@marge.simpson.net>
	 <CAOtvUMfhLQYK95uPm8idG_vYv-9yG2-KSkScjMBCSuvtffW1Dg@mail.gmail.com>
	 <1378797995.6046.54.camel@marge.simpson.net>
	 <CAOtvUMdRmDYP_e7eFX1akU8vZ=dcVOnFDrBjKufumOaBxxXF3A@mail.gmail.com>
	 <0000014109b5ec0e-ca64a736-ce4a-4be2-abf6-bbf2c1c15f80-000000@email.amazonses.com>
	 <1378869632.5476.34.camel@marge.simpson.net>
	 <000001410d659f85-21128fa5-a252-4006-804c-4ff03acbd50f-000000@email.amazonses.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1844
Lines: 43

On Wed, 2013-09-11 at 14:21 +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. And the mechanism adds some
> significant latencies to core memory management processing path.

You don't have to use or even configure in all controllers.

> Also many folks in finance like to deal directly with the hardware
> (processor numbers, affinity masks etc). There are already numerous ways
> to specify these masks. Pretty well established. Digging down a cpuset
> hierachy is a bit tedious. Then these cpusets can also overlap which
> makes the whole setup difficult.

These kind of things have to be exclusive set attributes 'course,
overlapping nohz_tick/full/off just ain't gonna work very well.

I hacked it up for my rt kernel to turn the tick on/off, and disable rt
load balancing (cpupri adds jitter) on a per exclusive set basis.  The
cpuset bit is easy.  Connecting buttons to scheduler and whatnot can
make cute little "You'd better not EVER submit this" warts though :)

> If cpusets can be used on top then ok but I would like it not to be
> required to have that compiled in.

IMHO, it makes much more sense to unify set attributes in cpusets,
fixing up or griping about whatever annoys HPC boxen/folks.

But whatever, I only piped in to mention that isolcpus wants to die, and
I've done that, so I can pipe-down now.

-Mike


--
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/