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.
>
>
next prev parent 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 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.