mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@kernel.org>
To: Eric Dumazet <edumazet@google.com>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [BUG] rcu-tasks : should take care of sparse cpu masks
Date: Thu, 31 Mar 2022 16:13:12 -0700	[thread overview]
Message-ID: <20220331231312.GA4285@paulmck-ThinkPad-P17-Gen-1> (raw)
In-Reply-To: <CANn89iJaeBneeqiDBUh_ppEQGne_eyPp-BCVYjEyvoYkUxrDxg@mail.gmail.com>

On Thu, Mar 31, 2022 at 03:57:36PM -0700, Eric Dumazet wrote:
> On Thu, Mar 31, 2022 at 3:54 PM Eric Dumazet <edumazet@google.com> wrote:
> >
> > On Thu, Mar 31, 2022 at 3:42 PM Paul E. McKenney <paulmck@kernel.org> wrote:
> > >
> > > On Thu, Mar 31, 2022 at 02:45:25PM -0700, Eric Dumazet wrote:
> > > > Hi Paul
> > > >
> > > > It seems you assume per cpu ptr for arbitrary indexes (< nr_cpu_ids) are valid.
> > >
> > > Gah!  I knew I was forgetting something...
> > >
> > > But just to check, is this a theoretical problem or something you hit
> > > on real hardware?  (For the rest of this email, I am assuming the latter.)
> >
> > Code review really...
> >
> > >
> > > > What do you think of the (untested) following patch ?
> > >
> > > One issue with this patch is that the contention could be unpredictable,
> > > or worse, vary among CPU, especially if the cpu_possible_mask was oddly
> > > distributed.
> > >
> > > So might it be better to restrict this to all on CPU 0 on the one hand
> > > and completely per-CPU on the other?  (Or all on the boot CPU, in case
> > > I am forgetting some misbegotten architecture that can run without a
> > > CPU 0.)
> >
> > If I understand correctly, cblist_init_generic() could setup
> > percpu_enqueue_shift
> > to something smaller than order_base_2(nr_cpu_ids)
> >
> > Meaning that we could reach a non zero idx in (smp_processor_id() >>
> > percpu_enqueue_shift)
> >
> > So even if CPU0 is always present (I am not sure this is guaranteed,
> > but this seems reasonable),
> > we could still attempt a per_cpu_ptr(PTR,  not_present_cpu), and get garbage.
> 
> Also you mention CPU 0, but I do not see where cpu binding is
> performed on the kthread ?

The initial setting of ->percpu_enqueue_shift forces all in-range CPU
IDs to shift down to zero.  The grace-period kthread is allowed to run
where it likes.  The callback lists are protected by locking, even in
the case of local access, so this should be safe.

Or am I missing your point?

							Thanx, Paul

> > > > Thanks.
> > > >
> > > > diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h
> > > > index 99cf3a13954cfb17828fbbeeb884f11614a526a9..df3785be4022e903d9682dd403464aa9927aa5c2
> > > > 100644
> > > > --- a/kernel/rcu/tasks.h
> > > > +++ b/kernel/rcu/tasks.h
> > > > @@ -273,13 +273,17 @@ static void call_rcu_tasks_generic(struct
> > > > rcu_head *rhp, rcu_callback_t func,
> > > >         bool needadjust = false;
> > > >         bool needwake;
> > > >         struct rcu_tasks_percpu *rtpcp;
> > > > +       int ideal_cpu, chosen_cpu;
> > > >
> > > >         rhp->next = NULL;
> > > >         rhp->func = func;
> > > >         local_irq_save(flags);
> > > >         rcu_read_lock();
> > > > -       rtpcp = per_cpu_ptr(rtp->rtpcpu,
> > > > -                           smp_processor_id() >>
> > > > READ_ONCE(rtp->percpu_enqueue_shift));
> > > > +
> > > > +       ideal_cpu = smp_processor_id() >> READ_ONCE(rtp->percpu_enqueue_shift);
> > > > +       chosen_cpu = cpumask_next(ideal_cpu - 1, cpu_online_mask);
> > > > +
> > > > +       rtpcp = per_cpu_ptr(rtp->rtpcpu, chosen_cpu);
> > > >         if (!raw_spin_trylock_rcu_node(rtpcp)) { // irqs already disabled.
> > > >                 raw_spin_lock_rcu_node(rtpcp); // irqs already disabled.
> > > >                 j = jiffies;

  reply	other threads:[~2022-03-31 23:13 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-31 21:45 Eric Dumazet
2022-03-31 22:42 ` Paul E. McKenney
2022-03-31 22:54   ` Eric Dumazet
2022-03-31 22:57     ` Eric Dumazet
2022-03-31 23:13       ` Paul E. McKenney [this message]
2022-03-31 23:28         ` Eric Dumazet
2022-04-01  0:06           ` Paul E. McKenney
2022-04-01  4:39             ` Eric Dumazet
2022-04-01 13:01               ` Paul E. McKenney
2022-04-01 13:24                 ` Eric Dumazet
2022-04-01 15:20                   ` Paul E. McKenney
2022-04-01 15:28                     ` Paul E. McKenney
2022-04-01 15:48                       ` Paul E. McKenney
2022-04-04  5:45                         ` Neeraj Upadhyay
2022-04-05  0:04                           ` KP Singh
2022-04-05 20:38                             ` Martin KaFai Lau
2022-04-06 15:44                               ` KP Singh
2022-04-12  6:28                                 ` KP Singh
2022-04-12 17:13                                   ` Martin KaFai Lau
2022-03-31 23:10     ` Paul E. McKenney
2022-04-04 19:49     ` Paul E. McKenney
2022-04-04 22:37       ` Eric Dumazet

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=20220331231312.GA4285@paulmck-ThinkPad-P17-Gen-1 \
    --to=paulmck@kernel.org \
    --cc=edumazet@google.com \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®