[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZwEfw3og4WuzXI7l@pavilion.home>
Date: Sat, 5 Oct 2024 13:15:15 +0200
From: Frederic Weisbecker <frederic@...nel.org>
To: Leonardo Bras Soares Passos <leobras@...hat.com>
Cc: Tejun Heo <tj@...nel.org>, Lai Jiangshan <jiangshanlai@...il.com>,
linux-kernel@...r.kernel.org, Junyao Zhao <junzhao@...hat.com>
Subject: Re: [PATCH v2 1/1] wq: Avoid using isolated cpus' timers on
queue_delayed_work
Le Fri, Oct 04, 2024 at 07:43:34PM -0300, Leonardo Bras Soares Passos a écrit :
> Well, back when it was merged, I could see add_timer() using an
> isolated CPU, and that's why I sent this change.
> Did this change recently?
That was (and still is) not supposed to happen because get_nohz_timer_target()
forbids that. Since then we have merged tmigr that also takes care of it.
So something looks broken...unless you had kernel.timer_migration=0 ?
>
> Also, previously add_timer() was only called if (cpu ==
> WORK_CPU_UNBOUND), and now we make sure that for any value of 'cpu'
> the timer to be put in a housekeeping cpu.
I suppose it makes the situation slightly less worse when a work is bound
to an isolated CPU. You get the workqueue without the timer. But the context
switch/workqueue is the most unwanted part :-)
Thanks.
>
> Thanks!
> Leo
>
> > Thanks.
> >
> > > add_timer_on(timer, cpu);
> > > - else
> > > - add_timer(timer);
> > > + } else {
> > > + if (likely(cpu == WORK_CPU_UNBOUND))
> > > + add_timer(timer);
> > > + else
> > > + add_timer_on(timer, cpu);
> > > + }
> >
> > > }
> > >
> > > /**
> > > --
> > > 2.43.0
> > >
> > >
> >
>
Powered by blists - more mailing lists