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

[Gabriele Monaco <gmonaco@redhat.com>]

On Thu, 2025-04-10 at 16:59 +0200, Frederic Weisbecker wrote:
> Le Thu, Apr 10, 2025 at 04:46:10PM +0200, Gabriele Monaco a écrit :
> > 
> > 
> > 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.
> 
> Easy but still a bit invasive so:
> 

I'm not understanding what is going to be invasive in this case.
Aren't we just talking about not allowing isolcpus to pull timers from
other cpus?
Let's ignore for now the global timers started on those CPUs, I'm not
aware of complaints regarding that.

As far as I understand, the change would allow timer migration to work
normally out of isolcpus and among housekeeping ones, we are not
forcing any migration that would potentially introduce overhead or
missed timers.
Or am I oversimplifying it?

Thanks,
Gabriele