[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130913092553.GL31370@twins.programming.kicks-ass.net>
Date: Fri, 13 Sep 2013 11:25:53 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Frederic Weisbecker <fweisbec@...il.com>
Cc: Christoph Lameter <cl@...ux.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Gilad Ben-Yossef <gilad@...yossef.com>,
Thomas Gleixner <tglx@...utronix.de>,
Mike Frysinger <vapier@...too.org>,
linux-kernel@...r.kernel.org,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Ingo Molnar <mingo@...nel.org>
Subject: Re: [RFC] Restrict kernel spawning of threads to a specified set of
cpus.
On Thu, Sep 12, 2013 at 08:30:25PM +0200, Frederic Weisbecker wrote:
> Now the issue doesn't only concern kthreads but all tasks in the system.
No, only kernel threads, all other tasks have a parent they inherit
(namespace, cgroup, affinity etc..) context from.
> If we really want to solve that race, then may be we can think of a kernel_parameter
No bloody kernel params. I'd much rather create a pointless kthread to
act as usermodehelper parent that people can set context on (move it
into cgroups, set affinity, whatever) so it automagically propagates to
all userspace helper thingies.
Is there anything other than usermodehelper we need to be concerned
with? One that comes to mind would be unbound workqueue threads. Do we
want to share the parent with usermodehelpers or have these two classes
have different parents?
--
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