Re: [PATCH v15 7/7] timers: Exclude isolated cpus from timer migration

[Frederic Weisbecker <frederic@kernel.org>]

Le Wed, Nov 19, 2025 at 11:10:58PM +0100, Thomas Gleixner a écrit :
> On Wed, Nov 19 2025 at 23:02, Frederic Weisbecker wrote:
> > Le Wed, Nov 19, 2025 at 10:23:11PM +0100, Thomas Gleixner a écrit :
> >> If you want to be a bit smarter, then you can just use a global mutex,
> >> which is taken inside the set/clear_available() functions which
> >> serializes the related functionality and bulk schedule/flush the unisol
> >> (make available) first and then proceed to the isol (make unavailable).
> >> 
> >> Then nothing has to change vs. the set/clear operations and everything
> >> just works.
> >> 
> >> That mutex does not do any harm in the CPU hotplug case and the
> >> serialization vs. the workers is not going to be the end of the world.
> >> 
> >> I'm willing to bet that no real-world use-case will ever notice the
> >> existance of this mutex. The microbenchmark which shows off the "I'm so
> >> smart" metric is completely irrelevant especially when the result is
> >> fragile, incomprehensible and therefore unmaintainable.
> >> 
> >> Keep it correct and simple is still the most important engineering
> >> principle. Premature optimization is a guaranteed path to failure.
> >> 
> >> If there is a compelling use case which justifies the resulting
> >> complexity, then it can be built on top. I'm not holding my breath. See
> >> above...
> >
> > Perhaps the only thing that worries me is if an isolated partition
> > is inverted. Say 0-3 is non isolated and 4-7 is isolated. And then
> > cpuset is overwritten so that the reverse is applied: 0-3 is isolated
> > and 4-7 is not isolated. If all isol works reach before unisol works,
> > then tmigr_clear_cpu_available() -> cpumask_any(tmigr_available_mask)
> > won't find any CPU left on the last call.
> 
> schedule the newly available (now unisolated) ones first and flush that
> work. After that you can safely mark the others unavailable, no?

Yes!

-- 
Frederic Weisbecker
SUSE Labs