All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Christoph Lameter <cl@linux.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Mike Galbraith <bitbucket@online.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Gilad Ben-Yossef <gilad@benyossef.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Mike Frysinger <vapier@gentoo.org>
Subject: Re: [PATCH] kmod: Run usermodehelpers only on cpus allowed for kthreadd V2
Date: Fri, 8 Nov 2013 17:31:14 +0100	[thread overview]
Message-ID: <20131108163112.GA12853@localhost.localdomain> (raw)
In-Reply-To: <0000014238407a1c-34e7bdbc-45c0-48de-a8a3-94a99f276044-000000@email.amazonses.com>

On Fri, Nov 08, 2013 at 03:06:59PM +0000, Christoph Lameter wrote:
> On Thu, 7 Nov 2013, Frederic Weisbecker wrote:
> 
> > usermodehelper works are created via workqueues, right? And workqueues are an issue as
> > well for those who want CPU isolation.
> 
> AFAICT usermodehelper can be called from a variety of contexts.

But it looks like it always end up calling a workqueue. May be I missed something though.

Now we can argue that this workqueue seem to create kernel threads, which in turn create other kernel thread (uhh?)
and I don't know if those inherit the kworker affinity. But from a quick look, it seems to me that
this is what we want.

BTW the use of kernel_thread is justified in this comment: "/* Keventd can't block, but this (a child) can. */"
Do these kernel_threads exist because kworker can't block? Actually the new workqueue subsystem can have blocking
worklets now, may be something can be simplified there although I haven't checked the details. But perhaps
we can spare one level of kernel threads.

Can't we use kthreads there btw? Or may be we need a task->mm to do the user things.

> 
> > So this looks like a more general problem than just call_usermodehelper.
> 
> Well the code explicitly sets the the affinity mask to all cpus which
> creates a problem for low latency processors. It does not inherit the
> affinity from any calling process.

But how is that an argument in favour of changing this to inheriting the affinity from
the workqueue thread rather than kthread?

> 
> > Last time I checked, it seemed to me that this is an unbound workqueue? If so can't we tune
> > the affinity of this workqueue? If not perhaps that's something we want to solve and which
> > could be useful for all the users who don't want their CPU to be disturbed.
> 
> There are various contexts from which usermodehelper can be called.
> Drivers use it etc.

But they all converge to the workqueue, or I'm missing other code paths?

Thanks.

  reply	other threads:[~2013-11-08 16:31 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-16 14:44 [PATCH] kmod: Run usermodehelpers only on cpus allowed for kthreadd Christoph Lameter
2013-10-16 21:13 ` Andrew Morton
2013-10-16 22:37   ` Christoph Lameter
2013-10-17 19:23     ` Andrew Morton
2013-11-07 16:43       ` [PATCH] kmod: Run usermodehelpers only on cpus allowed for kthreadd V2 Christoph Lameter
2013-11-07 22:50         ` Frederic Weisbecker
2013-11-08 15:06           ` Christoph Lameter
2013-11-08 16:31             ` Frederic Weisbecker [this message]
2013-11-08 17:05               ` Christoph Lameter
2013-11-08 19:12                 ` Frederic Weisbecker
2013-11-08 19:52                   ` Christoph Lameter
2013-11-08 20:06                     ` Frederic Weisbecker
2014-04-08 20:57                       ` Andrew Morton
2014-04-08 21:56                         ` Frederic Weisbecker
2013-10-17 13:55 ` [PATCH] kmod: Run usermodehelpers only on cpus allowed for kthreadd Frederic Weisbecker
2013-10-17 15:24   ` Christoph Lameter
2013-10-17 16:07     ` Frederic Weisbecker
2013-10-17 17:50       ` Andrew Morton
2013-10-17 18:24         ` Christoph Lameter
2013-10-17 22:27         ` Frederic Weisbecker
2013-10-20 18:00           ` Christoph Lameter
2013-10-17 18:23       ` Christoph Lameter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131108163112.GA12853@localhost.localdomain \
    --to=fweisbec@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=bitbucket@online.de \
    --cc=cl@linux.com \
    --cc=gilad@benyossef.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=vapier@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.