From: Yury Norov <firstname.lastname@example.org>
To: "Paul E. McKenney" <email@example.com>
Cc: Andy Shevchenko <firstname.lastname@example.org>,
Paul Gortmaker <email@example.com>,
Linux Kernel Mailing List <firstname.lastname@example.org>,
Li Zefan <email@example.com>, Ingo Molnar <firstname.lastname@example.org>,
Thomas Gleixner <email@example.com>,
Josh Triplett <firstname.lastname@example.org>,
Peter Zijlstra <email@example.com>,
Frederic Weisbecker <firstname.lastname@example.org>,
Rasmus Villemoes <email@example.com>
Subject: Re: [PATCH v4 0/8] support for bitmap (and hence CPU) list "N" abbreviation
Date: Thu, 11 Feb 2021 16:23:39 -0800 [thread overview]
Message-ID: <20210212002339.GA167389@yury-ThinkPad> (raw)
On Wed, Feb 10, 2021 at 04:23:09PM -0800, Paul E. McKenney wrote:
> On Wed, Feb 10, 2021 at 03:50:07PM -0800, Yury Norov wrote:
> > On Wed, Feb 10, 2021 at 9:57 AM Paul E. McKenney <firstname.lastname@example.org> wrote:
> > >
> > > On Wed, Feb 10, 2021 at 06:26:54PM +0200, Andy Shevchenko wrote:
> > > > On Tue, Feb 09, 2021 at 05:58:59PM -0500, Paul Gortmaker wrote:
> > > > > 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.
> > > >
> > > > I thought we kinda agreed that N is confusing and L is better.
> > > > N to me is equal to 32 on 32 core system as *number of cores / CPUs*. While L
> > > > sounds better as *last available CPU number*.
> > >
> > > The advantage of "N" is that people will automatically recognize it as
> > > "last thing" or number of things" because "N" has long been used in
> > > both senses. In contrast, someone seeing "0-L" for the first time is
> > > likely to go "What???".
> > >
> > > Besides, why would someone interpret "N" as "number of CPUs" when doing
> > > that almost always gets you an invalid CPU number?
> > >
> > > Thanx, Paul
> > I have no strong opinion about a letter, but I like Andy's idea to make it
> > case-insensitive.
> > There is another comment from the previous iteration not addressed so far.
> > This idea of the N notation is to make the bitmap list interface more robust
> > when we share the configs between different machines. What we have now
> > is definitely a good thing, but not completely portable except for cases
> > 'N', '0-N' and 'N-N'.
> > For example, if one user adds rcu_nocbs= '4-N', and it works perfectly fine for
> > him, another user with s NR_CPUS == 2 will fail to boot with such a config.
> > This is not a problem of course in case of absolute values because nobody
> > guaranteed robustness. But this N feature would be barely useful in practice,
> > except for 'N', '0-N' and 'N-N' as I mentioned before, because there's always
> > a chance to end up with a broken config.
> > We can improve on robustness a lot if we take care about this case.For me,
> > the more reliable interface would look like this:
> > 1. chunks without N work as before.
> > 2. if 'a-N' is passed where a>=N, we drop chunk and print warning message
> > 3. if 'a-N' is passed where a>=N together with a control key, we set last bit
> > and print warning.
> > For example, on 2-core CPU:
> > "4-2" --> error
> > "4-4" --> error
> > "4-N" --> drop and warn
> > "X, 4-N" --> set last bit and warn
> > Any comments?
> We really don't know the user's intent, and we cannot have complete
> portability without knowing the user's intent. For example, "4-N" means
> "all but the first four CPUs", in which case an error is appropriate
> because "4-N" makes no more sense on a 2-CPU system than does "4-1".
> I could see a potential desire for some notation for "the last two CPUs",
> but let's please have a real need for such a thing before overengineering
> this patch series any further.
> To get the level of portability you seem to be looking for, we need some
> higher-level automation that knows how many CPUs there are and what
> the intent is. That automation can then generate the cpumasks for a
> given system. But for more typical situations, what Paul has now will
> work fine.
> Paul Gortmaker's patch series is doing something useful. We should
> not let potential future desires prevent us from taking a very useful
> step forward.
> Thanx, Paul
No problem, we can do it later if it will become a real concern.
Can you please remove this series from linux-next unless we finish
the review? It prevents me from applying the series from the LKML.
next prev parent reply other threads:[~2021-02-12 0:24 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-09 22:58 [PATCH v4 0/8] support for bitmap (and hence CPU) list "N" abbreviation Paul Gortmaker
2021-02-09 22:59 ` [PATCH 1/8] lib: test_bitmap: clearly separate ERANGE from EINVAL tests Paul Gortmaker
2021-02-09 22:59 ` [PATCH 2/8] lib: test_bitmap: add tests to trigger ERANGE case Paul Gortmaker
2021-02-10 16:27 ` Andy Shevchenko
2021-02-09 22:59 ` [PATCH 3/8] lib: test_bitmap: add more start-end:offset/len tests Paul Gortmaker
2021-02-09 22:59 ` [PATCH 4/8] lib: bitmap: move ERANGE check from set_region to check_region Paul Gortmaker
2021-02-10 16:28 ` Andy Shevchenko
2021-02-09 22:59 ` [PATCH 5/8] lib: bitmap: pair nbits value with region struct Paul Gortmaker
2021-02-10 16:34 ` Andy Shevchenko
2021-02-09 22:59 ` [PATCH 6/8] lib: bitmap: support "N" as an alias for size of bitmap Paul Gortmaker
2021-02-09 23:16 ` Yury Norov
2021-02-10 15:58 ` Paul Gortmaker
2021-02-10 16:49 ` Andy Shevchenko
2021-02-12 1:24 ` Yury Norov
2021-02-21 8:07 ` Paul Gortmaker
2021-02-09 22:59 ` [PATCH 7/8] lib: test_bitmap: add tests for "N" alias Paul Gortmaker
2021-02-09 22:59 ` [PATCH 8/8] rcu: deprecate "all" option to rcu_nocbs= Paul Gortmaker
2021-02-10 16:26 ` [PATCH v4 0/8] support for bitmap (and hence CPU) list "N" abbreviation Andy Shevchenko
2021-02-10 17:57 ` Paul E. McKenney
2021-02-10 23:50 ` Yury Norov
2021-02-11 0:23 ` Paul E. McKenney
2021-02-12 0:23 ` Yury Norov [this message]
2021-02-12 0:38 ` Paul E. McKenney
2021-02-21 8:02 ` Paul Gortmaker
2021-02-11 11:04 ` Rasmus Villemoes
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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 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).