From: Gabriele Monaco <gmonaco@redhat.com>
To: Waiman Long <llong@redhat.com>,
linux-kernel@vger.kernel.org,
Anna-Maria Behnsen <anna-maria@linutronix.de>,
Frederic Weisbecker <frederic@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v11 8/8] timers: Exclude isolated cpus from timer migration
Date: Wed, 13 Aug 2025 17:20:56 +0200 [thread overview]
Message-ID: <b4e804c7f7b2661690144ae96a6526676d960a4c.camel@redhat.com> (raw)
In-Reply-To: <4b99074a-af21-4d14-b995-a4e62275a62f@redhat.com>
On Tue, 2025-08-12 at 13:20 -0400, Waiman Long wrote:
> On 8/8/25 12:01 PM, Gabriele Monaco wrote:
> > +static bool tmigr_should_isolate_cpu(int cpu, void *ignored)
> > +{
> > + /*
> > + * The tick CPU can be marked as isolated by the cpuset
> > code, however
> > + * we cannot mark it as unavailable to avoid having no
> > global migrator
> > + * for the nohz_full CPUs.
> > + */
> > + return tick_nohz_cpu_hotpluggable(cpu);
> > +}
> We may have to update the cpuset code to fail isolated partition
> formation if it includes the nohz_full tick CPU as that CPU cannot be
> fully isolated. That will also make this patch simpler.
Good idea, I can check that!
[...]
> > /*
> > * 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;
> > + }
> > + }
> > + return ret;
> > }
> Can you integrate the
> tick_nohz_cpu_hotpluggable/tmigr_should_isolate_cpu check into
> tmigr_set_cpu_available() instead of special-casing the tick CPU
> here?
I could but I'm afraid Thomas won't like that [1]:
> This is really horribly confusing. This function is also invoked from
> the CPU offline hotplug callback and in context of CPU hotplug this
> check makes absolutely no sense at all.
The whole thing changed a bit since then, but I think his point still
stands, tick_nohz_cpu_hotpluggable is not meaningful from hotplug
callbacks besides that very first invocation.
Or am I missing your point?
Thanks,
Gabriele
[1] - https://lore.kernel.org/lkml/875xgqqrel.ffs@tglx/
next prev parent reply other threads:[~2025-08-13 15:21 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-08 16:01 [PATCH v11 0/8] " 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 [this message]
2025-09-01 12:41 ` Frederic Weisbecker
2025-09-01 13:48 ` Gabriele Monaco
2025-09-01 21:11 ` Frederic Weisbecker
2025-09-02 11:08 ` Gabriele Monaco
2025-09-02 12:45 ` Frederic Weisbecker
2025-09-08 8:35 ` Gabriele Monaco
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=b4e804c7f7b2661690144ae96a6526676d960a4c.camel@redhat.com \
--to=gmonaco@redhat.com \
--cc=anna-maria@linutronix.de \
--cc=frederic@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llong@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
all inboxes | Powered by JetHome®