[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210106174551.GB16838@windriver.com>
Date: Wed, 6 Jan 2021 12:45:51 -0500
From: Paul Gortmaker <paul.gortmaker@...driver.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: paulmck@...nel.org, linux-kernel@...r.kernel.org,
yury.norov@...il.com, kernel-team@...com
Subject: Re: [PATCH RFC cpumask 4/5] cpumask: Add "last" alias for cpu list
specifications
[Re: [PATCH RFC cpumask 4/5] cpumask: Add "last" alias for cpu list specifications] On 06/01/2021 (Wed 10:49) Peter Zijlstra wrote:
> On Tue, Jan 05, 2021 at 04:49:55PM -0800, paulmck@...nel.org wrote:
> > From: Paul Gortmaker <paul.gortmaker@...driver.com>
> >
> > It seems that a common configuration is to use the 1st couple cores
> > for housekeeping tasks, and or driving a busy peripheral that generates
> > a lot of interrupts, or something similar.
[...]
> > A generic token replacement is used to substitute "last" with the
> > number of CPUs present before handing off to bitmap processing. But
> > it could just as easily be used to replace any placeholder token with
> > any other token or value only known at/after boot.
>
> Aside from the comments Yury made, on how all this is better in
> bitmap_parselist(), how about doing s/last/N/ here? For me something
> like: "4-N" reads much saner than "4-last".
OK, I can see N used as per university math classes... to indicate the
end point of a fixed set of numbers, but I confess to having had to
think about it for a bit (university was a long time ago). I don't have
any strong opinion one way or another -- "last" vs. "N"...
> Also, it might make sense to teach all this about core/node topology,
> but that's going to be messy. Imagine something like "Core1-CoreN" or
> "Nore1-NodeN" to mean the mask all/{Core,Node}0.
>
> And that is another feature that seems to be missing from parselist,
> all/except.
Seems reasonable, but I'm going to look at fixing up what I've got as
per Yury's comments before volunteering to muck around with more string
parsing code to add more features...
Thanks,
Paul.
--
Powered by blists - more mailing lists