From: Paul Gortmaker <firstname.lastname@example.org> To: email@example.com Cc: Paul Gortmaker <firstname.lastname@example.org>, Yury Norov <email@example.com>, Peter Zijlstra <firstname.lastname@example.org>, "Paul E. McKenney" <email@example.com>, Frederic Weisbecker <firstname.lastname@example.org>, Josh Triplett <email@example.com>, Thomas Gleixner <firstname.lastname@example.org>, Ingo Molnar <email@example.com>, Li Zefan <firstname.lastname@example.org> Subject: [PATCH v2 0/3] :support for bitmap (and hence CPU) list abbreviations Date: Thu, 21 Jan 2021 17:33:52 -0500 [thread overview] Message-ID: <email@example.com> (raw) 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. Looking around before starting, I noticed RCU already had a short-form abbreviation "all" -- but if we want to treat CPU lists in a uniform matter, then tokens shouldn't be implemented at a subsystem level and hence be subsystem specific; each with their own variations. So I moved "all" to global use - for boot args, and for cgroups. Then I added the inverse "none" and finally, the one I wanted -- "N". Originally I did this at the CPU subsys level, but Yury suggested it be moved down further to bitmap level itself, and that was good advice. Things got smaller and less complex. The use of "N" isn't a standalone word like "all" or "none". It will be a part of a complete range specification, possibly with CSV separate ranges before and after; like "nohz_full=5,6,8-N" or "nohz_full=2-N:3/4" Also tested the post-boot cgroup use case as per below: root@hackbox:/sys/fs/cgroup/cpuset# mkdir foo root@hackbox:/sys/fs/cgroup/cpuset# cd foo 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 all > cpuset.cpus root@hackbox:/sys/fs/cgroup/cpuset/foo# cat cpuset.cpus 0-15 root@hackbox:/sys/fs/cgroup/cpuset/foo# /bin/echo none > cpuset.cpus root@hackbox:/sys/fs/cgroup/cpuset/foo# cat cpuset.cpus root@hackbox:/sys/fs/cgroup/cpuset/foo# 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. --- [v1: https://lore.kernel.org/lkml/20210106004850.GA11682@paulmck-ThinkPad-P72/ [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. Combination of the two got rid of needing strword() and greatly reduced complexity and footprint of the change -- thanks! ] Cc: Yury Norov <firstname.lastname@example.org> Cc: Peter Zijlstra <email@example.com> Cc: "Paul E. McKenney" <firstname.lastname@example.org> Cc: Frederic Weisbecker <email@example.com> Cc: Josh Triplett <firstname.lastname@example.org> Cc: Thomas Gleixner <email@example.com> Cc: Ingo Molnar <firstname.lastname@example.org> Cc: Li Zefan <email@example.com> Paul Gortmaker (3): lib: add "all" and "none" as valid ranges to bitmap_parselist() rcu: dont special case "all" handling; let bitmask deal with it lib: support N as end of range in bitmap_parselist() .../admin-guide/kernel-parameters.rst | 15 +++++++++++ .../admin-guide/kernel-parameters.txt | 4 +-- kernel/rcu/tree_plugin.h | 13 +++------ lib/bitmap.c | 27 +++++++++++++++---- 4 files changed, 42 insertions(+), 17 deletions(-) -- 2.17.1
next reply other threads:[~2021-01-21 22:36 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-21 22:33 Paul Gortmaker [this message] 2021-01-21 22:33 ` [PATCH 1/3] lib: add "all" and "none" as valid ranges to bitmap_parselist() Paul Gortmaker 2021-01-22 0:07 ` Yury Norov 2021-01-22 4:34 ` Paul Gortmaker 2021-01-21 22:33 ` [PATCH 2/3] rcu: dont special case "all" handling; let bitmask deal with it Paul Gortmaker 2021-01-21 22:33 ` [PATCH 3/3] lib: support N as end of range in bitmap_parselist() Paul Gortmaker 2021-01-22 0:29 ` Yury Norov 2021-01-22 4:43 ` Paul Gortmaker 2021-01-22 23:08 ` Yury Norov 2021-01-26 17:18 ` Paul Gortmaker
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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH v2 0/3] :support for bitmap (and hence CPU) list abbreviations' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).