[PATCH 3/3] kmod: Remove unecessary explicit wide CPU affinity setting

From: Frederic Weisbecker
Date: Mon Jul 06 2015 - 11:34:17 EST


The call_usermodehelper_exec_[a]sync() kernel threads are created by
khelper precisely because we want them to be affine to all CPUs,
irrespective of any call_usermodehelper() caller with reduced CPU
affinity. So this explicit all-CPUs wide affinity forcing is useless.

Not only useless it even breaks nohz full. The housekeeping work
(general kernel internal code that user doesn't care much about) is
handled by a reduced set of CPUs in nohz full, precisely those that are
not included by nohz_full= kernel parameters. For example unbound
workqueues are handled by housekeeping CPUs. And we want the
usermodehelper tasks to be handled by housekeeping CPUs because they are
kernel internals that user critical nohz full work don't want to be
disturbed by.

In nohz full configurations, khelper will naturally be affine to
housekeeping CPUs and this housekeeping affinity is then inherited by
usermodehelper kernel threads. But the explicit call to
set_cpus_allowed_ptr() breaks that.

Simply remove it.

Cc: Rik van Riel <riel@xxxxxxxxxx>
Cc: Oleg Nesterov <oleg@xxxxxxxxxx>
Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
Cc: Christoph Lameter <cl@xxxxxxxxx>
Signed-off-by: Frederic Weisbecker <fweisbec@xxxxxxxxx>
---
kernel/kmod.c | 3 ---
1 file changed, 3 deletions(-)

diff --git a/kernel/kmod.c b/kernel/kmod.c
index f940b21..b89342b 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -223,9 +223,6 @@ static int call_usermodehelper_exec_async(void *data)
flush_signal_handlers(current, 1);
spin_unlock_irq(&current->sighand->siglock);

- /* We can run anywhere, unlike our parent keventd(). */
- set_cpus_allowed_ptr(current, cpu_all_mask);
-
/*
* Our parent is keventd, which runs with elevated scheduling priority.
* Avoid propagating that into the userspace child.
--
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/