From: Thomas Gleixner <tglx@linutronix.de>
To: Gabriele Monaco <gmonaco@redhat.com>,
linux-kernel@vger.kernel.org,
Anna-Maria Behnsen <anna-maria@linutronix.de>,
Frederic Weisbecker <frederic@kernel.org>,
Waiman Long <longman@redhat.com>
Cc: Gabriele Monaco <gmonaco@redhat.com>
Subject: Re: [PATCH] timers: Exclude isolated cpus from timer migation
Date: Thu, 10 Apr 2025 10:26:26 +0200 [thread overview]
Message-ID: <87ecy0tob1.ffs@tglx> (raw)
In-Reply-To: <20250410065446.57304-2-gmonaco@redhat.com>
On Thu, Apr 10 2025 at 08:54, Gabriele Monaco wrote:
>
> +/* cpumask excluded from migration */
> +static cpumask_var_t tmigr_unavailable_cpumask;
Why is this a negated mask instead of being the obvious and intuitive
available mask?
> if (firstexp != KTIME_MAX) {
> - migrator = cpumask_any_but(cpu_online_mask, cpu);
> + migrator = cpumask_nth_andnot(0, cpu_possible_mask,
> + tmigr_unavailable_cpumask);
That's exactly what this negated mask causes: incomprehensible code.
cpumask_clear_cpu(cpu, available_mask);
...
migrator = cpumask_first(available_mask);
is too simple and obvious, right?
> + /* Fall back to any online in case all are isolated. */
How can that happen? There is always at least _ONE_ housekeeping,
non-isolated, CPU online, no?
> + if (migrator >= nr_cpu_ids)
> + migrator = cpumask_any_but(cpu_online_mask, cpu);
> work_on_cpu(migrator, tmigr_trigger_active, NULL);
> }
>
> return 0;
> }
>
> -static int tmigr_cpu_online(unsigned int cpu)
> +static int tmigr_cpu_available(unsigned int cpu)
> {
> - struct tmigr_cpu *tmc = this_cpu_ptr(&tmigr_cpu);
> + struct tmigr_cpu *tmc = per_cpu_ptr(&tmigr_cpu, cpu);
>
> /* Check whether CPU data was successfully initialized */
> if (WARN_ON_ONCE(!tmc->tmgroup))
> return -EINVAL;
>
> + /* Silently ignore online requests if isolated */
This comment makes no sense.
/* Isolated CPUs are not participating in timer migration */
makes it entirely clear what this is about, no?
That brings me to the general design decision here. Your changelog
explains at great length WHAT the change is doing, but completely fails
to explain the consequences and the rationale why this is the right
thing to do.
By excluding the isolated CPUs from migration completely, any 'global'
timer, which is armed on such a CPU, has to be expired on that isolated
CPU. That's fundamentaly different from e.g. RCU isolation.
It might be the right thing to do and harmless, but without a proper
explanation it's a silent side effect of your changes, which leaves
people scratching their heads.
> + if (cpu_is_isolated(cpu))
> + return 0;
> raw_spin_lock_irq(&tmc->lock);
> - trace_tmigr_cpu_online(tmc);
> + trace_tmigr_cpu_available(tmc);
> tmc->idle = timer_base_is_idle();
> if (!tmc->idle)
> __tmigr_cpu_activate(tmc);
> - tmc->online = true;
> + tmc->available = true;
> + tmc->idle = true;
How so?
> + cpumask_clear_cpu(cpu, tmigr_unavailable_cpumask);
> raw_spin_unlock_irq(&tmc->lock);
> return 0;
> }
>
> +int tmigr_isolated_exclude_cpumask(cpumask_var_t exclude_cpumask)
cpumask_var_t is wrong here. 'const struct cpumask *' is what you want.
> +{
> + int cpu;
> + cpumask_var_t cpumask;
https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#coding-style-notes
> + if (!zalloc_cpumask_var(&cpumask, GFP_KERNEL))
> + return -ENOMEM;
> +
> + cpumask_copy(cpumask, tmigr_unavailable_cpumask);
What serializes this against concurrent CPU hotplug? I assume it's done
by the caller, but then this code should have a lockdep assert to
validate it. If it's not, then this is broken.
As it is serialized it does not need a copy either, right?
> + /* Was not excluded but should be excluded now. */
> + for_each_cpu_andnot(cpu, exclude_cpumask, cpumask)
> + tmigr_cpu_unavailable(cpu);
> +
> + /* Was excluded but should be included now */
> + for_each_cpu_andnot(cpu, cpumask, exclude_cpumask)
> + if (cpu_online(cpu))
> + tmigr_cpu_available(cpu);
My brain hurts by now.
for_each_cpu_and(cpu, available_mask, exclude_mask)
tmigr_cpu_unavailable(cpu);
for_each_cpu_andnot(cpu, cpu_online_mask, exclude_mask) {
if (!cpumask_test_cpu(cpu, available_mask))
tmigr_cpu_available(cpu);
}
No?
Also this patch is doing too many things at once. It want's to be split
into:
Patch 1: Rename 'online' to 'available' (bit and function names)
Patch 2: Add the available mask logic
Patch 3: Add the isolation functionality
Thanks,
tglx
next prev parent reply other threads:[~2025-04-10 8:26 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-10 6:54 [PATCH] timers: Exclude isolated cpus from timer migation Gabriele Monaco
2025-04-10 8:26 ` Thomas Gleixner [this message]
2025-04-10 10:38 ` Gabriele Monaco
2025-04-10 13:03 ` Frederic Weisbecker
2025-04-10 13:15 ` Thomas Gleixner
2025-04-10 13:27 ` Frederic Weisbecker
2025-04-10 13:56 ` Gabriele Monaco
2025-04-10 14:20 ` Frederic Weisbecker
2025-04-10 14:46 ` Thomas Gleixner
2025-04-10 14:54 ` Frederic Weisbecker
2025-04-10 15:06 ` Waiman Long
2025-04-10 14:46 ` Gabriele Monaco
2025-04-10 14:59 ` Frederic Weisbecker
2025-04-10 15:05 ` Gabriele Monaco
2025-04-10 15:32 ` Frederic Weisbecker
2025-04-11 7:08 ` Gabriele Monaco
2025-04-11 11:31 ` Frederic Weisbecker
2025-04-11 13:02 ` Gabriele Monaco
2025-04-11 22:57 ` Frederic Weisbecker
2025-04-14 8:06 ` Gabriele Monaco
2025-04-10 14:35 ` Waiman Long
2025-04-10 14:43 ` Frederic Weisbecker
2025-04-10 14:49 ` Gabriele Monaco
2025-04-10 14:50 ` Waiman Long
2025-04-10 14:56 ` Frederic Weisbecker
2025-04-10 13:08 ` Thomas Gleixner
2025-04-10 14:21 ` Waiman Long
2025-04-10 14:32 ` Waiman Long
2025-04-11 7:12 ` kernel test robot
2025-04-11 9:27 ` kernel test robot
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=87ecy0tob1.ffs@tglx \
--to=tglx@linutronix.de \
--cc=anna-maria@linutronix.de \
--cc=frederic@kernel.org \
--cc=gmonaco@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.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