On Tue, Jan 26, 2021 at 12:11:39PM -0500, Paul Gortmaker wrote: > While this is done for all bitmaps, the original use case in mind was > for CPU masks and cpulist_parse() as described below. > > It seems that a common configuration is to use the 1st couple cores for > housekeeping tasks. This tends to leave the remaining ones to form a > pool of similarly configured cores to take on the real workload of > interest to the user. > > So on machine A - with 32 cores, it could be 0-3 for "system" and then > 4-31 being used in boot args like nohz_full=, or rcu_nocbs= as part of > setting up the worker pool of CPUs. > > But then newer machine B is added, and it has 48 cores, and so while > the 0-3 part remains unchanged, the pool setup cpu list becomes 4-47. > > Multiple deployment becomes easier when we can just simply replace 31 > and 47 with "N" and let the system substitute in the actual number at > boot; a number that it knows better than we do.
I would accept lower 'n' as well. ... > -static const char *bitmap_getnum(const char *str, unsigned int *num) > +static const char *__bitmap_getnum(const char *str, unsigned int nbits, > + unsigned int *num) > { > unsigned long long n; > unsigned int len; > > + if (str[0] == 'N') { > + *num = nbits - 1; > + return str + 1; > + } But locating it here makes possible to enter a priori invalid input, like N for start of the region. I think this should be separate helper which is called in places where it makes sense. > len = _parse_integer(str, 10, &n); > if (!len) > return ERR_PTR(-EINVAL); -- With Best Regards, Andy Shevchenko