Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp970267pxb; Tue, 9 Feb 2021 18:23:21 -0800 (PST) X-Google-Smtp-Source: ABdhPJykql/KM4EZMxwBeEXm5zn9nnBV98qx9MY3ShsSsQTRm/wBlDXQae15JP3+g5jZDoExU4NT X-Received: by 2002:aa7:cd8d:: with SMTP id x13mr1053479edv.286.1612923801766; Tue, 09 Feb 2021 18:23:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612923801; cv=none; d=google.com; s=arc-20160816; b=JSw0BQNlAomMbn2gOVMOLI4hQxk7CIRNfV04d58cSxSKTA803cZPCqhw2SFNGzibAL 36SkH13Eqgb1uxdlSpNiMPHU8jcuIID9aDw//7W/+KzToHqocT0QPrxa7WyGk19Oj9LR oahJc2bn21FDRSSlZ+j3U+vvMTA3G7R6CbM4cruSpWJU8ysxJpqmWWiWY/XIjIuI3px5 t96MWfjrNSZ4aGOPHXBz8yFsOgunbq44kkxjLRmi3TK6Jk9Mco5/rvDciiXpHRTzqfQA rCC0/GtaL1W9DsahJFYc/pmqrgyXGHctRVp3xaKyZ4fKaUCW2xOG733pQHjZMeOhDnQ0 431A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:subject:cc:to:from; bh=7PR6wwA/frCVzqLVacCWthzarIRiLSZs2xqmC+nW86A=; b=CI1sk5v1cz1t9bk0Hty8TbcmT1nrNlbg4olbXewZWdOAbtoOEJA64IxFA7w7Plkd4q OaglXg4QHLdF2FzeszB5mfuFByU7wm7y11OSN1nngG+0q4X/MpdsNe9Et632AVqynsQC iae2mlcqIwwGIotbAT76fsfNfC7jQkhDRSg+RSFa9ISiaZE3D1DpBK6m/HpOUtLnuhoZ fqM6Mz+8GOgDhjbapRGEeyVronZDOKaGkTj4KTb2keSfPexmgTEc10ke/YI6EpTLbzap ePovu68BqKd/+xwRnL63Ki8ID/mckYWASUGOXMZB6MN2bv/GXpXOv8qcP4Tvq714GZ8h 8f/Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f7si313297eja.553.2021.02.09.18.22.57; Tue, 09 Feb 2021 18:23:21 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233686AbhBJCWS (ORCPT + 99 others); Tue, 9 Feb 2021 21:22:18 -0500 Received: from mail1.windriver.com ([147.11.146.13]:43196 "EHLO mail1.windriver.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234975AbhBJBgi (ORCPT ); Tue, 9 Feb 2021 20:36:38 -0500 X-Greylist: delayed 8888 seconds by postgrey-1.27 at vger.kernel.org; Tue, 09 Feb 2021 20:31:50 EST Received: from ala-exchng01.corp.ad.wrs.com (ala-exchng01.corp.ad.wrs.com [147.11.82.252]) by mail1.windriver.com (8.15.2/8.15.2) with ESMTPS id 119MxD1X026111 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 9 Feb 2021 14:59:18 -0800 (PST) Received: from ala-exchng01.corp.ad.wrs.com (147.11.82.252) by ala-exchng01.corp.ad.wrs.com (147.11.82.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 9 Feb 2021 14:59:12 -0800 Received: from yow-pgortmak-lx2.corp.ad.wrs.com (128.224.56.62) by ala-exchng01.corp.ad.wrs.com (147.11.82.252) with Microsoft SMTP Server id 15.1.2106.2 via Frontend Transport; Tue, 9 Feb 2021 14:59:11 -0800 From: Paul Gortmaker To: CC: Li Zefan , Ingo Molnar , Yury Norov , Thomas Gleixner , Josh Triplett , Peter Zijlstra , "Paul E. McKenney" , Frederic Weisbecker , Rasmus Villemoes , Andy Shevchenko , Paul Gortmaker Subject: [PATCH v4 0/8] support for bitmap (and hence CPU) list "N" abbreviation Date: Tue, 9 Feb 2021 17:58:59 -0500 Message-ID: <20210209225907.78405-1-paul.gortmaker@windriver.com> X-Mailer: git-send-email 2.17.1 MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The basic objective here was to add support for "nohz_full=8-N" and/or "rcu_nocbs="4-N" -- essentially introduce "N" as a portable reference to the last core, evaluated at boot for anything using a CPU list. The thinking behind this, is that people carve off a few early CPUs to support housekeeping tasks, and perhaps dedicate one to a busy I/O peripheral, and then the remaining pool of CPUs out to the end are a part of a commonly configured pool used for the real work the user cares about. Extend that logic out to a fleet of machines - some new, and some nearing EOL, and you've probably got a wide range of core counts to contend with - even though the early number of cores dedicated to the system overhead probably doesn't vary. This change would enable sysadmins to have a common bootarg across all such systems, and would also avoid any off-by-one fencepost errors that happen for users who might briefly forget that core counts start at zero. Originally I did this at the CPU subsys level, but Yury suggested it be moved down further to bitmap level itself, which made the core implementation smaller and less complex, but the series longer. New self tests are added to better exercise what bitmap range/region currently supports, and new tests are added for the new "N" support. Also tested boot arg and the post-boot cgroup use case as per below: root@hackbox:~# cat /proc/cmdline BOOT_IMAGE=/boot/bzImage root=/dev/sda1 rcu_nocbs=2,3,8-N:1/2 root@hackbox:~# dmesg|grep Offl rcu: Offload RCU callbacks from CPUs: 2-3,8,10,12,14. root@hackbox:/sys/fs/cgroup/cpuset/foo# cat cpuset.cpus root@hackbox:/sys/fs/cgroup/cpuset/foo# /bin/echo 10-N > cpuset.cpus root@hackbox:/sys/fs/cgroup/cpuset/foo# cat cpuset.cpus 10-15 root@hackbox:/sys/fs/cgroup/cpuset/foo# /bin/echo N-N:N/N > cpuset.cpus root@hackbox:/sys/fs/cgroup/cpuset/foo# cat cpuset.cpus 15 This was on a 16 core machine with CONFIG_NR_CPUS=16 in .config file. Note that "N" is a dynamic quantity, and can change scope if the bitmap is changed in size. So at the risk of stating the obvious, don't use it for "burn_eFuse=128-N" or "secure_erase_firmware=32-N" type stuff. Paul. --- I've intentionally not gone down the rabbit hole of whether N or Z or L is the better letter to mark the end of a mathematical set in the hope that we can stay focused, and get this closed out here in v4. Aside from that, I believe all other feedback has been responded to in one way or another. Note that I didn't add Reviewed/Ack tags to anything that changed significantly from what was reviewed in v3. [v4: pair nbits with region, instead of inside it. Split EINVAL and ERANGE tests. Don't handle start/end/offset within a macro to abstract away nbits usage. Added some Reviwed-by/Ack tags.] [v3: Allow "N" to be used anywhere in the region spec, i.e. "N-N:N/N" vs. just being allowed at end of range like "0-N". Add new self-tests. Drop "all" and "none" aliases as redundant and not worth the extra complication. ] https://lore.kernel.org/lkml/20210126171141.122639-1-paul.gortmaker@windriver.com [v2: push code down from cpu subsys to core bitmap code as per Yury's comments. Change "last" to simply be "N" as per PeterZ.] https://lore.kernel.org/lkml/20210121223355.59780-1-paul.gortmaker@windriver.com/ [v1: https://lore.kernel.org/lkml/20210106004850.GA11682@paulmck-ThinkPad-P72/ Cc: Li Zefan Cc: Ingo Molnar Cc: Yury Norov Cc: Thomas Gleixner Cc: Josh Triplett Cc: Peter Zijlstra Cc: "Paul E. McKenney" Cc: Frederic Weisbecker Cc: Rasmus Villemoes Cc: Andy Shevchenko Paul Gortmaker (8): lib: test_bitmap: clearly separate ERANGE from EINVAL tests. lib: test_bitmap: add tests to trigger ERANGE case. lib: test_bitmap: add more start-end:offset/len tests lib: bitmap: move ERANGE check from set_region to check_region lib: bitmap: pair nbits value with region struct lib: bitmap: support "N" as an alias for size of bitmap lib: test_bitmap: add tests for "N" alias rcu: deprecate "all" option to rcu_nocbs= .../admin-guide/kernel-parameters.rst | 7 +++ .../admin-guide/kernel-parameters.txt | 4 +- kernel/rcu/tree_plugin.h | 6 +- lib/bitmap.c | 62 +++++++++++++------ lib/test_bitmap.c | 46 ++++++++++++-- 5 files changed, 93 insertions(+), 32 deletions(-) -- 2.17.1