From: Thomas Gleixner <tglx@linutronix.de>
To: Frederic Weisbecker <frederic@kernel.org>
Cc: 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>,
paulmck@kernel.org, Anna-Maria Behnsen <anna-maria@linutronix.de>
Subject: Re: [PATCH 1/3 v3] hrtimers: Force migrate away hrtimers queued after CPUHP_AP_HRTIMERS_DYING
Date: Fri, 17 Jan 2025 16:20:00 +0100 [thread overview]
Message-ID: <87ikqda2n3.ffs@tglx> (raw)
In-Reply-To: <Z4plCGNJddH-BDWE@localhost.localdomain>
On Fri, Jan 17 2025 at 15:11, Frederic Weisbecker wrote:
> Le Thu, Jan 16, 2025 at 11:59:48AM +0100, Thomas Gleixner a écrit :
>> > + if (enqueue_hrtimer(timer, new_base, mode))
>> > + smp_call_function_single_async(cpu, &new_cpu_base->csd);
>>
>> Duh. This reimplementation of switch_hrtimer_base() is really aweful. We
>> can be smarter than that. Untested patch below.
>
> Indeed, and I tried to "fix" switch_hrtimer_base() but didn't managed to do
> it properly. Looks like you did :-)
>
> But I have a few comments:
>
>> @@ -208,6 +211,13 @@ struct hrtimer_cpu_base *get_target_base
>> if (static_branch_likely(&timers_migration_enabled) && !pinned)
>> return &per_cpu(hrtimer_bases, get_nohz_timer_target());
>> #endif
>> +#ifdef CONFIG_HOTPLUG_CPU
>> + if (unlikely(!base->online)) {
>> + int cpu = cpumask_any_and(cpu_online_mask, housekeeping_cpumask(HK_TYPE_TIMER));
>> +
>> + return &per_cpu(hrtimer_bases, cpu);
>> + }
>> +#endif
>
> This should be at the beginning of get_target_base(), otherwise the target may
> end up being the local one.
Indeed. As I said, it's untested.
>> - if (new_cpu_base != this_cpu_base &&
>> + if (new_cpu_base != this_cpu_base && this_cpu_base->online &&
>> hrtimer_check_target(timer, new_base)) {
>> raw_spin_unlock(&new_base->cpu_base->lock);
>> raw_spin_lock(&base->cpu_base->lock);
>
> This forget the case where the elected remote target is the same as the old one,
> but its next event is after the timer. In that case this default to local, even
> if it is offline.
*blink*
> How about this? (untested yet)
> -static int
> -hrtimer_check_target(struct hrtimer *timer, struct hrtimer_clock_base *new_base)
> +static bool
> +hrtimer_suitable_target(struct hrtimer *timer,
> + struct hrtimer_clock_base *new_base,
> + struct hrtimer_cpu_base *new_cpu_base,
> + struct hrtimer_cpu_base *this_cpu_base)
> {
> ktime_t expires;
>
> + /* The local CPU clockevent can be reprogrammed */
> + if (new_cpu_base == this_cpu_base)
> + return true;
That needs a comment explaining that @new_cpu_base is guaranteed not to
be @this_cpu_base if @this_cpu_base->online == false due to the magic in
get_target_base(). That's far from obvious.
I had to stare at it 5 times to convince myself that this is correct.
Other than that, this looks about right.
Thanks,
tglx
next prev parent reply other threads:[~2025-01-17 15:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-31 17:07 [PATCH 0/3 v3] hrtimer: Fix timers queued locally from offline CPUs Frederic Weisbecker
2024-12-31 17:07 ` [PATCH 1/3 v3] hrtimers: Force migrate away hrtimers queued after CPUHP_AP_HRTIMERS_DYING Frederic Weisbecker
2025-01-16 10:59 ` Thomas Gleixner
2025-01-17 14:11 ` Frederic Weisbecker
2025-01-17 15:20 ` Thomas Gleixner [this message]
2024-12-31 17:07 ` [PATCH 2/3 v3] rcu: Remove swake_up_one_online() bandaid Frederic Weisbecker
2024-12-31 17:07 ` [PATCH 3/3 v3] Revert "rcu/nocb: Fix rcuog wake-up from offline softirq" Frederic Weisbecker
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=87ikqda2n3.ffs@tglx \
--to=tglx@linutronix.de \
--cc=Cheng-Jui.Wang@mediatek.com \
--cc=anna-maria@linutronix.de \
--cc=boqun.feng@gmail.com \
--cc=frederic@kernel.org \
--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=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.