public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <frederic@kernel.org>
To: Peter Zijlstra <peterz@infradead.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:23:31 +0200	[thread overview]
Message-ID: <ZkYW48dTX2FH5NaD@lothringen> (raw)
In-Reply-To: <20240516140003.GJ22557@noisy.programming.kicks-ass.net>

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/

Because all we need now is:

_ HK_TYPE_KERNEL_NOISE: nohz_full= or isolcpus=nohz
_ HK_TYPE_DOMAIN: isolcpus=domain (or classic isolcpus= alone)
_ 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.

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?

Thanks.



> 
> If the CPU participates in load-balancing, it gets to fully participate.
> If you want to get out of load-balancing, you get single CPU partitions.

  reply	other threads:[~2024-05-16 14:23 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 [this message]
2024-05-16 14:45                     ` Peter Zijlstra
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=ZkYW48dTX2FH5NaD@lothringen \
    --to=frederic@kernel.org \
    --cc=Markus.Elfring@web.de \
    --cc=anna-maria@linutronix.de \
    --cc=dietmar.eggemann@arm.com \
    --cc=joel@joelfernandes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox