From: Gabriele Monaco <gmonaco@redhat.com>
To: Frederic Weisbecker <frederic@kernel.org>
Cc: linux-kernel@vger.kernel.org,
Anna-Maria Behnsen <anna-maria@linutronix.de>,
Thomas Gleixner <tglx@linutronix.de>,
Waiman Long <longman@redhat.com>
Subject: Re: [PATCH v11 8/8] timers: Exclude isolated cpus from timer migration
Date: Mon, 01 Sep 2025 15:48:15 +0200 [thread overview]
Message-ID: <d001f1bc9a87e031cf4f8721d6843013c766c28a.camel@redhat.com> (raw)
In-Reply-To: <aLWUkpKgFFVr_TEx@localhost.localdomain>
On Mon, 2025-09-01 at 14:41 +0200, Frederic Weisbecker wrote:
> Le Fri, Aug 08, 2025 at 06:01:42PM +0200, Gabriele Monaco a écrit :
> > /*
> > * NOHZ can only be enabled after clocksource_done_booting().
> > Don't
> > * bother trashing the cache in the tree before.
> > */
> > static int __init tmigr_late_init(void)
> > {
> > - return cpuhp_setup_state(CPUHP_AP_TMIGR_ONLINE,
> > "tmigr:online",
> > - tmigr_set_cpu_available,
> > tmigr_clear_cpu_available);
> > + int cpu, ret;
> > +
> > + ret = cpuhp_setup_state(CPUHP_AP_TMIGR_ONLINE,
> > "tmigr:online",
> > + tmigr_set_cpu_available,
> > tmigr_clear_cpu_available);
> > + if (ret)
> > + return ret;
> > + /*
> > + * The tick CPU may not be marked as available in the
> > above call, this
> > + * can occur only at boot as hotplug handlers are not
> > called on the
> > + * tick CPU. Force it enabled here.
> > + */
> > + for_each_possible_cpu(cpu) {
> > + if (!tick_nohz_cpu_hotpluggable(cpu)) {
> > + ret = smp_call_function_single(
> > + cpu, tmigr_cpu_unisolate_force,
> > NULL, 1);
> > + break;
> > + }
> > + }
>
> Why not evaluate tick_nohz_cpu_hotpluggable() from
> tmigr_clear_cpu_available() instead of this force IPI?
The idea is that this IPI runs once during late boot only for the tick
CPU, while the call to tick_nohz_cpu_hotpluggable() would be running at
every hotplug event if I move it to tmigr_clear_cpu_available.
In that scenario, it's guaranteed to return true (besides the very
first call).
I don't have a strong opinion against running that check every time
although it's needed only at boot time and remove this IPI, but in my
understanding that's one of the thing Thomas was finding confusing [1].
Am I missing anything here?
> But if I understand correctly, this will be handled by cpuset, right?
Currently tick_nohz_cpu_hotpluggable() is called by
tmigr_should_isolate_cpu() and that is called by cpuset code, changing
cpuset would save that call but won't deal with the tick CPU not
enabled at boot time, unless I'm misunderstanding what Waiman implied.
Thanks,
Gabriele
[1] - https://lore.kernel.org/lkml/875xgqqrel.ffs@tglx
next prev parent reply other threads:[~2025-09-01 13:48 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-08 16:01 [PATCH v11 0/8] timers: Exclude isolated cpus from timer migration Gabriele Monaco
2025-08-08 16:01 ` [PATCH v11 1/8] timers/migration: Postpone online/offline callbacks registration to late initcall Gabriele Monaco
2025-08-08 16:01 ` [PATCH v11 2/8] timers: Rename tmigr 'online' bit to 'available' Gabriele Monaco
2025-08-08 16:01 ` [PATCH v11 3/8] timers: Add the available mask in timer migration Gabriele Monaco
2025-08-08 16:01 ` [PATCH v11 4/8] timers: Use scoped_guard when setting/clearing the tmigr available flag Gabriele Monaco
2025-08-08 16:01 ` [PATCH v11 5/8] cgroup/cpuset: Rename update_unbound_workqueue_cpumask() to update_exclusion_cpumasks() Gabriele Monaco
2025-08-08 16:01 ` [PATCH v11 6/8] sched/isolation: Force housekeeping if isolcpus and nohz_full don't leave any Gabriele Monaco
2025-08-12 15:29 ` Waiman Long
2025-09-02 12:19 ` Frederic Weisbecker
2025-08-08 16:01 ` [PATCH v11 7/8] cgroup/cpuset: Fail if isolated and nohz_full don't leave any housekeeping Gabriele Monaco
2025-08-12 15:40 ` Waiman Long
2025-08-12 16:41 ` Waiman Long
2025-08-08 16:01 ` [PATCH v11 8/8] timers: Exclude isolated cpus from timer migration Gabriele Monaco
2025-08-12 17:20 ` Waiman Long
2025-08-13 15:20 ` Gabriele Monaco
2025-09-01 12:41 ` Frederic Weisbecker
2025-09-01 13:48 ` Gabriele Monaco [this message]
2025-09-01 21:11 ` Frederic Weisbecker
2025-09-02 11:08 ` Gabriele Monaco
2025-09-02 12:45 ` Frederic Weisbecker
2025-08-27 19:52 ` [PATCH v11 0/8] " John B. Wyatt IV
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=d001f1bc9a87e031cf4f8721d6843013c766c28a.camel@redhat.com \
--to=gmonaco@redhat.com \
--cc=anna-maria@linutronix.de \
--cc=frederic@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=tglx@linutronix.de \
/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;
as well as URLs for NNTP newsgroup(s).