Linux RCU subsystem development
 help / color / mirror / Atom feed
From: Frederic Weisbecker <frederic@kernel.org>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>,
	vlad.wing@gmail.com, rcu@vger.kernel.org, boqun.feng@gmail.com,
	joel@joelfernandes.org, neeraj.upadhyay@amd.com,
	urezki@gmail.com, qiang.zhang1211@gmail.com,
	Cheng-Jui.Wang@mediatek.com, leitao@debian.org,
	kernel-team@meta.com, Usama Arif <usamaarif642@gmail.com>,
	Anna-Maria Behnsen <anna-maria@linutronix.de>
Subject: Re: [PATCH 0/3] hrtimer: Fix timers queued locally from offline CPUs
Date: Sat, 21 Dec 2024 00:26:01 +0100	[thread overview]
Message-ID: <Z2X9CYoZVnvRncM8@pavilion.home> (raw)
In-Reply-To: <4fbc9ab5-43f3-47b7-a8df-27a8e6cf7040@paulmck-laptop>

Le Fri, Dec 20, 2024 at 03:19:31PM -0800, Paul E. McKenney a écrit :
> On Thu, Dec 19, 2024 at 09:42:48AM -0800, Paul E. McKenney wrote:
> > On Wed, Dec 18, 2024 at 05:50:05PM +0100, Frederic Weisbecker wrote:
> > > 5c0930ccaad5 ("hrtimers: Push pending hrtimers away from outgoing CPU earlier")
> > > was introduced to fix stalls with scheduler bandwidth timers getting
> > > migrated while some kthreads handling CPU hotplug rely on bandwidth.
> > > 
> > > However this has introduced several other issues which used to be
> > > confined to RCU. But not anymore as it is spreading to hotplug code
> > > itself (https://lore.kernel.org/all/20241213203739.1519801-1-usamaarif642@gmail.com/)
> > > 
> > > Instead of introducing yet another new hackery, fix the problem in
> > > hrtimers for everyone.
> > 
> > The good news is that this passes 12 hours of 400*TREE03.  (Yay!!!)
> > 
> > The so-so news is that this gives only about 70% confidence that these
> > patches help, but on the other hand, it also gives much higher confidence
> > that these patches are not hurting anything.
> > 
> > At least for TREE03.
> 
> Another day, another 12 hours of 400*TREE03 passed.  This gets us up
> beyond 90% confidence that these patches help, and even more confidence
> that they are not too severely hurting anything.

Cool :-)

> 
> > The not-so-good news is that this series causes build failures for
> > rcutorture scenarios (such as SRCU-T) that build with CONFIG_SMP=n:
> > 
> > ------------------------------------------------------------------------
> > kernel/time/hrtimer.c: In function ‘enqueue_hrtimer_offline’:
> > kernel/time/hrtimer.c:1229:42: error: ‘migration_base’ undeclared (first use in this function); did you mean ‘is_migration_base’?
> > ------------------------------------------------------------------------
> > 
> > When built with KCSAN enabled (--kcsan to kvm.sh), there is this
> > additional build failure on that same line of code:
> > 
> > ------------------------------------------------------------------------
> > kernel/time/hrtimer.c:1229:3: error: incompatible pointer types assigning to 'volatile typeof (timer->base)' (aka 'struct hrtimer_clock_base *volatile') from 'bool (*)(struct hrtimer_clock_base *)' (aka '_Bool (*)(struct hrtimer_clock_base *)') [-Werror,-Wincompatible-pointer-types]
> > 
> >  1229 |                 WRITE_ONCE(timer->base, &migration_base);
> > ------------------------------------------------------------------------
> > 
> > Me, I am a bit surprised that enqueue_hrtimer_offline() is even built
> > in a CONFIG_SMP=n kernel.
> > 
> > But there might be some reason why #ifdef-ing out that function's body
> > would be a bad idea, so over to you!  ;-)
> 
> Curiosity overcame me, and the #ifdef makes things at least appear to
> work for CONFIG_SMP=n kernels.  Experimental patch below, which I intend
> to use for further testing, but I have no plans to push it upstream.
> 
> 							Thanx, Paul
> 
> ------------------------------------------------------------------------
> 
> commit 61a0b92b3a3cfef69e3848806e51d1b99a9e9406
> Author: Paul E. McKenney <paulmck@kernel.org>
> Date:   Fri Dec 20 15:10:26 2024 -0800
> 
>     EXP hrtimers: No-op enqueue_hrtimer_offline() if !HOTPLUG_CPU
>     
>     In kernels built with CONFIG_HOTPLUG_CPU=n, this experimental commit
>     uses #ifdef to remove the body of the enqueue_hrtimer_offline() function.
>     This might or might not be the correct fix to the build complaint about
>     migration_base being undeclared.
>     
>     Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
>     Cc: Vlad Poenaru <vlad.wing@gmail.com>
>     Cc: Usama Arif <usamaarif642@gmail.com>
>     Cc: Frederic Weisbecker <frederic@kernel.org>
> 
> diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
> index 48c0078d2c4f2..4235b7825b152 100644
> --- a/kernel/time/hrtimer.c
> +++ b/kernel/time/hrtimer.c
> @@ -1213,6 +1213,7 @@ static void enqueue_hrtimer_offline(struct hrtimer *timer,
>  				    struct hrtimer_clock_base *base,
>  				    const enum hrtimer_mode mode)
>  {
> +#ifdef CONFIG_HOTPLUG_CPU
>  	struct hrtimer_cpu_base *new_cpu_base, *old_cpu_base, *this_cpu_base;
>  	struct hrtimer_clock_base *new_base;
>  	int cpu;
> @@ -1238,6 +1239,7 @@ static void enqueue_hrtimer_offline(struct hrtimer *timer,
>  
>  	if (enqueue_hrtimer(timer, new_base, mode))
>  		smp_call_function_single_async(cpu, &new_cpu_base->csd);
> +#endif
>  }

I was thinking about something like that. Can I fold that and add your
SOB?

Thanks.

>  
>  

  reply	other threads:[~2024-12-20 23:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-18 16:50 [PATCH 0/3] hrtimer: Fix timers queued locally from offline CPUs Frederic Weisbecker
2024-12-18 16:50 ` [PATCH 1/3] hrtimers: Force migrate away hrtimers queued after CPUHP_AP_HRTIMERS_DYING Frederic Weisbecker
2024-12-19 19:00   ` Usama Arif
2024-12-20 23:43     ` Frederic Weisbecker
2024-12-18 16:50 ` [PATCH 2/3] rcu: Remove swake_up_one_online() bandaid Frederic Weisbecker
2024-12-18 16:50 ` [PATCH 3/3] Revert "rcu/nocb: Fix rcuog wake-up from offline softirq" Frederic Weisbecker
2024-12-19 17:42 ` [PATCH 0/3] hrtimer: Fix timers queued locally from offline CPUs Paul E. McKenney
2024-12-20 23:19   ` Paul E. McKenney
2024-12-20 23:26     ` Frederic Weisbecker [this message]
2024-12-21  0:05       ` Paul E. McKenney

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=Z2X9CYoZVnvRncM8@pavilion.home \
    --to=frederic@kernel.org \
    --cc=Cheng-Jui.Wang@mediatek.com \
    --cc=anna-maria@linutronix.de \
    --cc=boqun.feng@gmail.com \
    --cc=joel@joelfernandes.org \
    --cc=kernel-team@meta.com \
    --cc=leitao@debian.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neeraj.upadhyay@amd.com \
    --cc=paulmck@kernel.org \
    --cc=qiang.zhang1211@gmail.com \
    --cc=rcu@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=urezki@gmail.com \
    --cc=usamaarif642@gmail.com \
    --cc=vlad.wing@gmail.com \
    /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