All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yury Norov <yury.norov@gmail.com>
To: paulmck@kernel.org
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Paul Gortmaker <paul.gortmaker@windriver.com>,
	kernel-team@fb.com, Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH RFC cpumask] Allow "all", "none", and "last" in cpumask strings
Date: Wed, 20 Jan 2021 23:11:48 -0800	[thread overview]
Message-ID: <CAAH8bW8-q-2LaTC5DE0PnUBqs3V_69EAefLvwdZoeFSow8NYZA@mail.gmail.com> (raw)
In-Reply-To: <CAAH8bW95nyx6PEnPiBPoHMLoduvgU9KO7N=K7mhLORkA+zzhDw@mail.gmail.com>

On Wed, Jan 6, 2021 at 12:49 AM Yury Norov <yury.norov@gmail.com> wrote:
>
> On Tue, Jan 5, 2021 at 4:48 PM Paul E. McKenney <paulmck@kernel.org> wrote:
> >
> > Hello!
> >
> > This series allows "all", "none", and "last" to be used in cpumask
> > strings.  This allows these strings to be less dependent on the underlying
> > system.  For example, currently a string specifying all but the first
> > CPU must be "1-7" on an eight-CPU system and "1-15" on a 16-CPU system.
> > With this series, the single string "1-last" can be used regardless of the
> > number of CPUs (at least assuming that each system has at least one CPU).
>
> 'none' may be implemented as an empty string or string with separators only,
> but I have nothing against explicit 'none'. See other comments inline.
>
> Thanks,
> Yury.
>
> > 1.      Un-inline cpulist_parse for SMP; prepare for ascii helpers,
> >         courtesy of Paul Gortmaker.
> >
> > 2.      Make "all" alias global and not just RCU, courtesy of Paul
> >         Gortmaker.
> >
> > 3.      Add a "none" alias to complement "all", courtesy of Paul
> >         Gortmaker.
> >
> > 4.      Add "last" alias for cpu list specifications, courtesy of Paul
> >         Gortmaker.
> >
> > 5.      Use "all" and "last" in "nohz_full" and "rcu_nocbs".
> >
> >                                                 Thanx, Paul

Hi Paul,

Today I found this series in linux-next despite downsides discovered during
the review. This series introduces absolutely unneeded cap on the number of
cpus in the system (9999), and also adds unsafe and non-optimal code.

In addition to that, I observe this warning on powerpc:
  CC      lib/cpumask.o
lib/cpumask.c: In function ‘cpulist_parse’:
lib/cpumask.c:222:17: warning: cast from pointer to integer of
different size [-Wpointer-to-int-cast]
  222 |   memblock_free((phys_addr_t)cpulist, len);
      |                 ^

Can you please revert this series unless all the problems will be fixed?

Thanks,
Yury

  reply	other threads:[~2021-01-21  7:14 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-06  0:48 [PATCH RFC cpumask] Allow "all", "none", and "last" in cpumask strings Paul E. McKenney
2021-01-06  0:49 ` [PATCH RFC cpumask 1/5] cpumask: Un-inline cpulist_parse for SMP; prepare for ascii helpers paulmck
2021-01-06  0:49 ` [PATCH RFC cpumask 2/5] cpumask: Make "all" alias global and not just RCU paulmck
2021-01-06  6:32   ` Yury Norov
2021-01-06  0:49 ` [PATCH RFC cpumask 3/5] cpumask: Add a "none" alias to complement "all" paulmck
2021-01-06  6:59   ` Yury Norov
2021-01-06  0:49 ` [PATCH RFC cpumask 4/5] cpumask: Add "last" alias for cpu list specifications paulmck
2021-01-06  8:41   ` Yury Norov
2021-01-06  9:49   ` Peter Zijlstra
2021-01-06 17:45     ` Paul Gortmaker
2021-01-06 21:16     ` Yury Norov
2021-01-07 14:18       ` Peter Zijlstra
2021-01-07 14:47         ` Paul E. McKenney
2021-01-07 14:59           ` Peter Zijlstra
2021-01-07 15:32             ` Paul E. McKenney
2021-01-07 15:05         ` Paul E. McKenney
2021-01-06  0:49 ` [PATCH RFC cpumask 5/5] rcutorture: Use "all" and "last" in "nohz_full" and "rcu_nocbs" paulmck
2021-01-06  8:49 ` [PATCH RFC cpumask] Allow "all", "none", and "last" in cpumask strings Yury Norov
2021-01-21  7:11   ` Yury Norov [this message]
2021-01-21 16:57     ` Paul E. McKenney
2021-01-21 21:39       ` Paul E. McKenney
2021-01-21 22:42     ` 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 \
    --in-reply-to=CAAH8bW8-q-2LaTC5DE0PnUBqs3V_69EAefLvwdZoeFSow8NYZA@mail.gmail.com \
    --to=yury.norov@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paul.gortmaker@windriver.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.