[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZkYnKAd1Qy+yvjDY@lothringen>
Date: Thu, 16 May 2024 17:32:56 +0200
From: Frederic Weisbecker <frederic@...nel.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Yun Levi <ppbuk5246@...il.com>, Joel Fernandes <joel@...lfernandes.org>,
Vineeth Pillai <vineeth@...byteword.org>,
Vincent Guittot <vincent.guittot@...aro.org>,
Dietmar Eggemann <dietmar.eggemann@....com>,
anna-maria@...utronix.de, mingo@...nel.org, tglx@...utronix.de,
Markus.Elfring@....de, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4] time/tick-sched: idle load balancing when nohz_full
cpu becomes idle.
On Thu, May 16, 2024 at 05:19:53PM +0200, Peter Zijlstra wrote:
> On Thu, May 16, 2024 at 05:02:51PM +0200, Frederic Weisbecker wrote:
>
> > > I'm confused, none of that makes sense. If you're part of a
> > > load-balancer, you're part of a load-balancer, no ifs buts or other
> > > nonsense.
> > >
> > > idle load balancer is no different from regular load balancing.
> > >
> > > Fundamentally, you can't disable the tick if you're part of a
> > > load-balance group, the load-balancer needs the tick.
> > >
> > > The only possible way to use nohz_full is to not be part of a
> > > load-balancer, and the only way that is so is by having (lots of) single
> > > CPU partitions.
> >
> > So you're suggesting that nohz_full should just be part of the whole
> > ilb machinery by default (that is, not fiddle with ilb internals) and
> > then it's up to CPU partitioning (through cpuset or isolcpus) to disable
> > ilb naturally. Right?
>
> Yes, but stronger, as long as the CPU is part of a load-balance domain,
> it must not disable the tick while running anything.
>
> that is, NOHZ_FULL must not become active unless it's running on a
> single CPU partition.
I like the idea but I'm afraid to introduce regressions while doing so,
with people currently using nohz_full without proper partionning...
Powered by blists - more mailing lists