From: Oleg Nesterov <oleg@redhat.com>
To: Tejun Heo <htejun@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
zhang.yi20@zte.com.cn, lkml <linux-kernel@vger.kernel.org>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Ingo Molnar <mingo@redhat.com>
Subject: Re: [PATCH]: exec: avoid propagating PF_NO_SETAFFINITY into userspace child
Date: Thu, 28 Nov 2013 16:00:55 +0100 [thread overview]
Message-ID: <20131128150055.GA11956@redhat.com> (raw)
In-Reply-To: <20131128143155.GC3925@htj.dyndns.org>
On 11/28, Tejun Heo wrote:
>
> * Is WQ_RESCUER actually necessary? If not, WQ_RESCUER will be
> dropped and the task bearing the name of the workqueue will no
> longer exist.
WQ_MEM_RECLAIM, I guess. Probably not...
> * Is ordered execution necessary? If not, it can be converted to
> alloc_workqueue() or just to use system_wq.
I think no. This is the reason for kmod_thread_locker hack.
> khelper is special as its attributes get inherited to its children,
> so, yeah, we probably wanna keep that one's cpumask set to all.
And btw. Note ____call_usermodehelper()->set_cpus_allowed_ptr(cpu_all_mask).
Even if we change the affinity of the "khelper" worker threads this
won't restrict the user-space helpers.
I think this set_cpus_allowed_ptr() should die in any case?
Oleg.
next prev parent reply other threads:[~2013-11-28 15:45 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-14 1:51 kmod: avoid propagating PF_NO_SETAFFINITY into userspace child zhang.yi20
2013-11-14 5:23 ` Tejun Heo
2013-11-14 11:40 ` Oleg Nesterov
2013-11-14 11:55 ` [PATCH 0/1]: (Was: kmod: avoid propagating PF_NO_SETAFFINITY into userspace child) Oleg Nesterov
2013-11-14 11:56 ` [PATCH 1/1] workqueue: swap set_cpus_allowed_ptr() and PF_NO_SETAFFINITY Oleg Nesterov
2013-11-22 23:13 ` Tejun Heo
[not found] ` <OF36E72FA9.51146BE3-ON48257C2E.0008BC6D-48257C2E.0008FF9C@zte.com.cn>
2013-11-25 12:14 ` 答复: " Oleg Nesterov
2013-11-26 2:10 ` [PATCH]: exec: avoid propagating PF_NO_SETAFFINITY into userspace child zhang.yi20
2013-11-26 18:04 ` Oleg Nesterov
2013-11-27 2:07 ` zhang.yi20
2013-11-27 13:20 ` Oleg Nesterov
2013-11-27 18:31 ` Tejun Heo
2013-11-28 9:13 ` Peter Zijlstra
2013-11-28 11:45 ` Oleg Nesterov
2013-11-28 12:17 ` Peter Zijlstra
2013-11-28 13:31 ` Oleg Nesterov
2013-11-28 13:39 ` Peter Zijlstra
2013-11-28 14:13 ` Tejun Heo
2013-11-28 14:31 ` Peter Zijlstra
2013-11-28 14:38 ` Tejun Heo
2013-11-28 14:47 ` Peter Zijlstra
2013-11-28 14:51 ` Tejun Heo
2013-11-28 14:55 ` Peter Zijlstra
2013-11-28 14:57 ` Tejun Heo
2013-11-28 14:59 ` Peter Zijlstra
2013-11-28 15:07 ` Tejun Heo
2013-11-28 15:17 ` Peter Zijlstra
2013-11-28 15:39 ` Tejun Heo
2013-11-28 16:33 ` Peter Zijlstra
2013-11-29 14:33 ` Tejun Heo
2013-11-28 15:47 ` Oleg Nesterov
2013-11-28 16:07 ` Oleg Nesterov
2013-11-28 14:43 ` Peter Zijlstra
2013-11-28 14:53 ` Tejun Heo
2013-11-28 14:57 ` Peter Zijlstra
2013-11-28 15:02 ` Tejun Heo
2013-11-28 15:07 ` Peter Zijlstra
2013-11-28 15:10 ` Tejun Heo
2013-11-28 15:18 ` Peter Zijlstra
2013-11-28 14:38 ` Peter Zijlstra
2013-11-28 14:45 ` Tejun Heo
2013-11-28 14:53 ` Peter Zijlstra
2013-11-28 15:34 ` Oleg Nesterov
2013-11-28 15:40 ` Peter Zijlstra
2013-11-28 16:20 ` Oleg Nesterov
2013-11-28 16:38 ` Peter Zijlstra
2013-11-28 18:13 ` Oleg Nesterov
2013-11-28 14:23 ` Oleg Nesterov
2013-11-28 14:31 ` Tejun Heo
2013-11-28 15:00 ` Oleg Nesterov [this message]
2013-11-28 15:02 ` Peter Zijlstra
2013-11-28 19:33 ` [PATCH 0/1] usermodehelper: kill ____call_usermodehelper()->set_cpus_allowed_ptr() Oleg Nesterov
2013-11-28 19:33 ` [PATCH 1/1] " Oleg Nesterov
2013-11-29 13:44 ` Tejun Heo
2013-11-29 16:49 ` Oleg Nesterov
2013-12-05 14:21 ` Frederic Weisbecker
2013-12-05 14:37 ` Oleg Nesterov
2013-12-05 14:39 ` Tejun Heo
2013-12-05 15:30 ` Oleg Nesterov
2013-12-05 19:13 ` Christoph Lameter
2013-12-06 14:53 ` Oleg Nesterov
2013-12-06 15:37 ` Christoph Lameter
2013-12-06 15:56 ` Oleg Nesterov
2013-12-05 16:26 ` Frederic Weisbecker
2013-12-05 14:42 ` Frederic Weisbecker
2013-11-28 13:41 ` [PATCH]: exec: avoid propagating PF_NO_SETAFFINITY into userspace child Peter Zijlstra
2013-11-28 14:05 ` Tejun Heo
2013-11-28 14:34 ` Oleg Nesterov
-- strict thread matches above, loose matches on Subject: below --
2013-11-29 9:19 zhang.yi20
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=20131128150055.GA11956@redhat.com \
--to=oleg@redhat.com \
--cc=htejun@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=peterz@infradead.org \
--cc=zhang.yi20@zte.com.cn \
/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.