From: Oleg Nesterov <oleg@redhat.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Christoph Lameter <cl@linux.com>, Rik van Riel <riel@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 2/5] kmod: Use system_unbound_wq instead of khelper
Date: Fri, 10 Jul 2015 00:44:06 +0200 [thread overview]
Message-ID: <20150709224406.GA17528@redhat.com> (raw)
In-Reply-To: <1436465237-22031-3-git-send-email-fweisbec@gmail.com>
On 07/09, Frederic Weisbecker wrote:
>
> We need to launch the usermodehelper kernel threads with the widest
> affinity and this is why we have khelper for. This workqueue has unbound
> properties and thus a wide affinity inherited by all its children.
>
> Now khelper also has special properties that we aren't much interested
> in: ordered and singlethread. There is really no need about ordering as
> all we do is creating kernel threads. This can be done concurrently.
> And singlethread is a useless limitation as well.
>
> The workqueue engine already proposes generic unbound workqueues that
> don't share these useless properties and handle well parallel jobs.
>
> Lets just use them.
>
> Suggested-by: Oleg Nesterov <oleg@redhat.com>
Well yes, but it seems that you missed another part of my email ;)
If we just change usermodehelper to use system_unbound_wq then we
probably should keep set_cpus_allowed_ptr() removed by 4/5.
Note that system_unbound_wq has ->no_numa == F, so its worker threads
are NUMA bound. Perhaps this is not that bad, I do not know. But at
least this means that 4/5 needs more documentation/justification.
But as for this particular patch I obviously like it, khelper_wq
must die imo ;)
Oleg.
next prev parent reply other threads:[~2015-07-09 22:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-09 18:07 [PATCH 0/5] kmod: Simplifications and cleanups v2 Frederic Weisbecker
2015-07-09 18:07 ` [PATCH 1/5] kmod: Bunch of internal functions renames Frederic Weisbecker
2015-07-09 18:07 ` [PATCH 2/5] kmod: Use system_unbound_wq instead of khelper Frederic Weisbecker
2015-07-09 22:44 ` Oleg Nesterov [this message]
2015-07-10 13:47 ` Frederic Weisbecker
2015-07-10 14:20 ` Christoph Lameter
2015-07-10 17:12 ` Frederic Weisbecker
2015-07-10 17:52 ` Christoph Lameter
2015-07-10 18:10 ` Frederic Weisbecker
2015-07-10 19:05 ` Christoph Lameter
2015-07-14 14:04 ` Frederic Weisbecker
2015-07-09 18:07 ` [PATCH 3/5] kmod: Add up-to-date explanations on the purpose of each asynchronous levels Frederic Weisbecker
2015-07-09 18:07 ` [PATCH 4/5] kmod: Remove unecessary explicit wide CPU affinity setting Frederic Weisbecker
2015-07-09 18:07 ` [RFC PATCH 5/5] kmod: Handle UMH_WAIT_PROC from system unbound workqueue Frederic Weisbecker
2015-07-09 22:51 ` Oleg Nesterov
2015-07-10 13:57 ` Frederic Weisbecker
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=20150709224406.GA17528@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@redhat.com \
/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.