Re: [PATCH] timers: Exclude isolated cpus from timer migation

[Gabriele Monaco <gmonaco@redhat.com>]

On Thu, 2025-04-10 at 16:20 +0200, Frederic Weisbecker wrote:
> Le Thu, Apr 10, 2025 at 03:56:02PM +0200, Gabriele Monaco a écrit :
> > On Thu, 2025-04-10 at 15:27 +0200, Frederic Weisbecker wrote:
> > > But how do we handle global timers that have been initialized and
> > > queued from
> > > isolated CPUs?
> > 
> > I need to sketch a bit more the solution but the rough idea is:
> > 1. isolated CPUs don't pull remote timers
> 
> That's the "easy" part.
> 
> > 2. isolated CPUs ignore their global timers and let others pull
> > them
> >   perhaps with some more logic to avoid it expiring
> 
> This will always involve added overhead because you may need to wake
> up
> a CPU upon enqueueing a global timer to make sure it will be handled.
> At least when all other CPUs are idle.
> 
> > Wouldn't that be sufficient?
> > 
> > Also, I would definitely do 1. for any kind of isolation, but I'm
> > not
> > sure about 2.
> > Strictly speaking domain isolated cores don't claim to be free of
> > kernel noise, even if they initiate it (but nohz_full ones do).
> > What would be the expectation there?
> 
> I don't know, I haven't heard complains about isolcpus handling
> global
> timers so far...
> 
> I wouldn't pay much attention to 2) until anybody complains. Does 1)
> even
> matter to anybody outside nohz_full ?
> 

Makes sense..
In our case, 2. is not a big issue because it can usually be solved by
other configurations, but 1. is an issue.
Most people indeed use nohz_full in that scenario, but some users may
not want its overhead.

I find it misleading at best for global timers to migrate from
housekeeping to isolcpus cores and since it's "easy", I'd definitely
change that.

Does it make sense?

Thanks,
Gabriele