From: Peter Zijlstra <peterz@infradead.org>
To: Frederic Weisbecker <frederic@kernel.org>
Cc: Yun Levi <ppbuk5246@gmail.com>,
Joel Fernandes <joel@joelfernandes.org>,
Vineeth Pillai <vineeth@bitbyteword.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
anna-maria@linutronix.de, mingo@kernel.org, tglx@linutronix.de,
Markus.Elfring@web.de, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4] time/tick-sched: idle load balancing when nohz_full cpu becomes idle.
Date: Thu, 16 May 2024 16:45:04 +0200 [thread overview]
Message-ID: <20240516144504.GL22557@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <ZkYW48dTX2FH5NaD@lothringen>
On Thu, May 16, 2024 at 04:23:31PM +0200, Frederic Weisbecker wrote:
> On Thu, May 16, 2024 at 04:00:03PM +0200, Peter Zijlstra wrote:
> > > If I make you annoyed I'm sorry in advance but let me clarify please.
> > >
> > > 1. In case of none-HK-TICK-housekeeping cpu (a.k.a nohz_full cpu),
> > > It should be on the null_domain. right?
> > >
> > > 2. If (1) is true, when none-HK-TICK is set, should it set none-HK-DOMAIN
> > > to prevent on any sched_domain (cpusets filter out none-HK-DOMAIN cpu)?
> > >
> > > 3. If (1) is true, Is HK_SCHED still necessary? There seems to be no use case
> > > and the check for this can be replaced by on_null_domain().
> >
> > I've no idea about all those HK knobs, it's all insane if you ask me.
> >
> > Frederic, afaict all the HK_ goo in kernel/sched/fair.c is total
> > nonsense, can you please explain?
>
> Yes. Lemme unearth this patch:
> https://lore.kernel.org/all/20230203232409.163847-2-frederic@kernel.org/
AFAICT we need more cleanups.
> Because all we need now is:
>
> _ HK_TYPE_KERNEL_NOISE: nohz_full= or isolcpus=nohz
> _ HK_TYPE_DOMAIN: isolcpus=domain (or classic isolcpus= alone)
What does this do?
> _ HK_TYPE_MANAGED_IRQ: isolcpus=managed_irq
>
> And that's it. Then let's remove HK_TYPE_SCHED that is unused. And then
> lemme comment the HK_TYPE_* uses within sched/* within the same
> patchset.
Please, I find this MISC and DOMAIN stuff confusing, wth does it do? It
can't possibly be right.
> Just a question, correct me if I'm wrong, we don't want nohz_full= to ever
> take the idle load balancer duty (this is what HK_TYPE_MISC prevents in
> find_new_ilb) because the nohz_full CPU going back to userspace concurrently
> doesn't want to be disturbed by a loose IPI telling it to do idle balancing. But
> we still want nohz_full CPUs to be part of nohz.idle_cpus_mask so that the
> idle balancing can be performed on them by a non isolated CPU. Right?
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.
next prev parent reply other threads:[~2024-05-16 14:45 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-06 21:31 [PATCH] time/tick-sched: enable idle load balancing when nohz_full cpu becomes idle Levi Yun
2024-05-08 9:18 ` Markus Elfring
2024-05-09 9:59 ` Dan Carpenter
2024-05-08 17:26 ` [PATCH v2] time/tick-sched: " Levi Yun
2024-05-08 18:38 ` Markus Elfring
2024-05-08 19:15 ` Yun Levi
2024-05-08 19:22 ` [PATCH v3] " Levi Yun
2024-05-09 6:28 ` Markus Elfring
2024-05-09 7:26 ` Yun Levi
2024-05-09 8:16 ` Markus Elfring
2024-05-09 9:22 ` Yun Levi
2024-05-09 9:40 ` [v3] " Markus Elfring
2024-05-09 9:29 ` [PATCH v4] " Levi Yun
2024-05-09 9:55 ` [v4] " Markus Elfring
2024-05-15 16:41 ` [PATCH v4] " Yun Levi
2024-05-15 22:52 ` Frederic Weisbecker
2024-05-16 5:29 ` Yun Levi
2024-05-16 7:56 ` Peter Zijlstra
2024-05-16 8:20 ` Yun Levi
2024-05-16 8:49 ` Peter Zijlstra
2024-05-16 11:25 ` Frederic Weisbecker
2024-05-16 12:43 ` Yun Levi
2024-05-16 14:00 ` Peter Zijlstra
2024-05-16 14:23 ` Frederic Weisbecker
2024-05-16 14:45 ` Peter Zijlstra [this message]
2024-05-16 15:02 ` Frederic Weisbecker
2024-05-16 15:19 ` Peter Zijlstra
2024-05-16 15:32 ` Frederic Weisbecker
2024-05-16 16:12 ` Yun Levi
2024-05-16 17:53 ` Peter Zijlstra
2024-05-17 14:50 ` Frederic Weisbecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240516144504.GL22557@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=Markus.Elfring@web.de \
--cc=anna-maria@linutronix.de \
--cc=dietmar.eggemann@arm.com \
--cc=frederic@kernel.org \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=ppbuk5246@gmail.com \
--cc=tglx@linutronix.de \
--cc=vincent.guittot@linaro.org \
--cc=vineeth@bitbyteword.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.