[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5886464d-a867-471e-858e-b4ed732a1d76@web.de>
Date: Thu, 9 May 2024 10:16:15 +0200
From: Markus Elfring <Markus.Elfring@....de>
To: Yun Levi <ppbuk5246@...il.com>, kernel-janitors@...r.kernel.org,
Anna-Maria Behnsen <anna-maria@...utronix.de>,
Frederic Weisbecker <frederic@...nel.org>, Ingo Molnar <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>
Cc: LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3] time/tick-sched: idle load balancing when nohz_full
cpu becomes idle.
>>> +++ b/kernel/time/tick-sched.c
>>> @@ -1228,8 +1228,10 @@ void tick_nohz_idle_stop_tick(void)
>>> ts->idle_sleeps++;
>>> ts->idle_expires = expires;
>>>
>>> - if (!was_stopped && tick_sched_flag_test(ts, TS_FLAG_STOPPED)) {
>>> - ts->idle_jiffies = ts->last_jiffies;
>>> + if (tick_sched_flag_test(ts, TS_FLAG_STOPPED)) {
>>> + if (!was_stopped)
>>> + ts->idle_jiffies = ts->last_jiffies;
>>> +
>>> nohz_balance_enter_idle(cpu);
>>> }
…
> So, I think it's enough in commit message?
…
We are trying to clarify special implementation details here.
Our corresponding wording preferences are probably different.
I hope that a better common understanding can be achieved also for
another transformation.
* Thus I became curious how you got interested to adjust this software
component further.
* Will any other data representation become more helpful for the circumstances
according to calls of a function like “tick_nohz_idle_stop_tick”?
* How do you think about to stress condition ordering concerns around
the system configuration “nohz_full”?
* How will related changelogs evolve further?
Regards,
Markus
Powered by blists - more mailing lists