Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762065Ab3JPVN3 (ORCPT ); Wed, 16 Oct 2013 17:13:29 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:37424 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753455Ab3JPVN2 (ORCPT ); Wed, 16 Oct 2013 17:13:28 -0400 Date: Wed, 16 Oct 2013 14:13:26 -0700 From: Andrew Morton To: Christoph Lameter Cc: Frederic Weisbecker , Mike Galbraith , Thomas Gleixner , Gilad Ben-Yossef , "linux-kernel@vger.kernel.org" , "Paul E. McKenney" , Mike Frysinger Subject: Re: [PATCH] kmod: Run usermodehelpers only on cpus allowed for kthreadd Message-Id: <20131016141326.2e517e18e4d8af880c97a282@linux-foundation.org> In-Reply-To: <00000141c1b99b20-64f9d142-961a-447e-8ebe-40f86b638278-000000@email.amazonses.com> References: <00000141c1b99b20-64f9d142-961a-447e-8ebe-40f86b638278-000000@email.amazonses.com> X-Mailer: Sylpheed 3.2.0beta5 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2501 Lines: 71 On Wed, 16 Oct 2013 14:44:28 +0000 Christoph Lameter wrote: > This is a follow on patch related to the earlier > discussion about restricting the > spawning of kernel threads. See https://lkml.org/lkml/2013/9/5/426 > > > > > usermodehelper() threads can currently run on all processors. > This is an issue for low latency cores. How much of an issue? The severity of the problem is utterly unclear from this description. > Restrict usermodehelper() threads to the cores that kthreadd is > restricted to. > > The default for kthreadd is to be allowed to run on an processors. > If the user restricts kthreadd then threads spawned by > usermodhelper() will similarly restricted. > > Before this patch there is no way to limit the cpus that usermodehelper > can run on since the affinity is set when the thread is spawned to > all processors. > > ... > > --- linux.orig/include/linux/kthread.h 2013-10-10 11:00:34.167771996 -0500 > +++ linux/include/linux/kthread.h 2013-10-15 13:57:52.859056676 -0500 > @@ -51,6 +51,7 @@ void kthread_parkme(void); > int kthreadd(void *unused); > extern struct task_struct *kthreadd_task; > extern int tsk_fork_get_node(struct task_struct *tsk); > +void set_kthreadd_affinity(void); > > /* > * Simple work processor based on kthread. > Index: linux/kernel/kmod.c > =================================================================== > --- linux.orig/kernel/kmod.c 2013-10-10 11:00:39.091771917 -0500 > +++ linux/kernel/kmod.c 2013-10-15 14:02:01.904261324 -0500 > @@ -40,6 +40,7 @@ > #include > #include > #include > +#include > > #include > > @@ -209,8 +210,8 @@ static int ____call_usermodehelper(void > flush_signal_handlers(current, 1); > spin_unlock_irq(¤t->sighand->siglock); > > - /* We can run anywhere, unlike our parent keventd(). */ > - set_cpus_allowed_ptr(current, cpu_all_mask); > + /* We can run anywhere kthreadd can run */ This is a poor comment - it explains "what" (which was utterly obvious) but doesn't explain "why". The reader will want to know *why* call_usermodehelper() only runs on kthreadd CPUs, but we didn't tell him. > + set_kthreadd_affinity(); > -- 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/