Received-SPF: pass (google.com: domain of linux-kernel+bounces-174345-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
MIME-Version: 1.0
References: <20240508172621.30069-1-ppbuk5246@gmail.com> <20240508192213.31050-1-ppbuk5246@gmail.com>
 <a407d12f-6845-4f51-a112-6bdc17641ff1@web.de> <CAM7-yPS6ecODhv-FQpYE5OE_LufmtKRg4htp9JH6MBUF03N4rA@mail.gmail.com>
 <5886464d-a867-471e-858e-b4ed732a1d76@web.de>
In-Reply-To: <5886464d-a867-471e-858e-b4ed732a1d76@web.de>
From: Yun Levi <ppbuk5246@gmail.com>
Date: Thu, 9 May 2024 10:22:10 +0100
Message-ID: <CAM7-yPT7z6phHOUVOMxebRxiqw6un1N3hQK6O2AeRfmnJhK4kA@mail.gmail.com>
Subject: Re: [PATCH v3] time/tick-sched: idle load balancing when nohz_full
 cpu becomes idle.
To: Markus Elfring <Markus.Elfring@web.de>
Cc: kernel-janitors@vger.kernel.org, 
	Anna-Maria Behnsen <anna-maria@linutronix.de>, Frederic Weisbecker <frederic@kernel.org>, 
	Ingo Molnar <mingo@kernel.org>, Thomas Gleixner <tglx@linutronix.de>, 
	LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Markus.
.

> * Will any other data representation become more helpful for the circumst=
ances
>   according to calls of a function like =E2=80=9Ctick_nohz_idle_stop_tick=
=E2=80=9D?

Maybe not in this commit..?


> * How do you think about stress condition ordering concerns around
>   the system configuration =E2=80=9Cnohz_full=E2=80=9D?

Well.. regardless of the stress condition, it wants to fix the
inconsistent behavior
happening when enter "idle state"

Let's think about two cases:
     1. nohz_full cpu stop tick in tick_nohz_irq_exiit() while it runs
only 1 cfs task.
     2. nohz_full cpu which doesn't stop the tick and switches to idle task=
.

Without this commit, case (1) wouldn't participate in idle balance
when it switches to idle task while its tick is already stopped.

case (2) although nohz_full cpu participates in idle balcancing
because former clock isn't stopped yet.


> * How will related changelogs evolve further?
>

Thanks for the suggestion. But I'll add some more background commit
message then.

Thanks again :)