Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753941AbbG0Q13 (ORCPT ); Mon, 27 Jul 2015 12:27:29 -0400 Received: from mail-wi0-f178.google.com ([209.85.212.178]:34441 "EHLO mail-wi0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753083AbbG0Q12 (ORCPT ); Mon, 27 Jul 2015 12:27:28 -0400 From: Frederic Weisbecker To: LKML Cc: Frederic Weisbecker , Tejun Heo , Oleg Nesterov , Christoph Lameter , Rik van Riel , Andrew Morton Subject: [PATCH 0/5] kmod: Cleanups, simplifications, and make isolation friendly v3 Date: Mon, 27 Jul 2015 18:27:15 +0200 Message-Id: <1438014440-20669-1-git-send-email-fweisbec@gmail.com> X-Mailer: git-send-email 2.1.4 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2441 Lines: 63 This patchset does a bunch of cleanups and converts khelper to use system unbound workqueues. The 3 first patches should be uncontroversial. The last 2 patches are debatable. Kmod creates kernel threads that perform userspace jobs and we want those to have a large affinity in order not to contend busy CPUs. This is (partly) why we use khelper which has a wide affinity that the kernel threads it create can inherit from. Now khelper is a dedicated workqueue that has singlethread properties which we aren't interested in. Hence those two debatable changes: _ We would like to use generic workqueues. System unbound workqueues are a very good candidate but they are not wide affine, only node affine. Now probably a node is enough to perform many parallel kmod jobs. _ We would like to remove the wait_for_helper kernel thread (UMH_WAIT_PROC handler) to use the workqueue. It means that if the workqueue blocks, and no other worker can take pending kmod request, we can be screwed. Now if we have 512 threads, this should be enough. I added Tejun to discuss these things. Changes since v2, after Oleg reviews: * Reordered patches such that the uncontroversial patches begin the queue and can be applied independantly. * Tell about the need for workqueue also because we want a privileged (root) thread for usermodehelper job. * Deactivate signal after UMH_WAIT_PROC handler. * Update comment to handle the fact system unbound workqueues are node affine and not wide affine. --- git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git nohz/kmod-v3 HEAD: 470ed6f10191864d28d2c8f4fd8a349ef58f427b Thanks, Frederic --- Frederic Weisbecker (5): kmod: Bunch of internal functions renames kmod: Remove unecessary explicit wide CPU affinity setting kmod: Add up-to-date explanations on the purpose of each asynchronous levels kmod: Use system_unbound_wq instead of khelper kmod: Handle UMH_WAIT_PROC from system unbound workqueue include/linux/kmod.h | 2 -- init/main.c | 1 - kernel/kmod.c | 91 ++++++++++++++++++++++++++++------------------------ 3 files changed, 49 insertions(+), 45 deletions(-) -- 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/