From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: Chen Yu <yu.c.chen@intel.com>
Cc: Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
Qais Yousef <qyousef@layalina.io>,
Kajetan Puchalski <kajetan.puchalski@arm.com>,
Morten Rasmussen <morten.rasmussen@arm.com>,
Vincent Donnefort <vdonnefort@google.com>,
Quentin Perret <qperret@google.com>,
Abhijeet Dharmapurikar <adharmap@quicinc.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] sched: Consider CPU contention in frequency & load-balance busiest CPU selection
Date: Fri, 5 May 2023 20:02:36 +0200 [thread overview]
Message-ID: <8276e5ce-b1f6-19e2-095b-abc6952bd1c7@arm.com> (raw)
In-Reply-To: <ZFSr4Adtx1ZI8hoc@chenyu5-mobl1>
Hi Chenyu,
On 05/05/2023 09:10, Chen Yu wrote:
> On 2023-04-06 at 17:50:30 +0200, Dietmar Eggemann wrote:
>> Use new cpu_boosted_util_cfs() instead of cpu_util_cfs().
>>
>> The former returns max(util_avg, runnable_avg) capped by max CPU
>> capacity. CPU contention is thereby considered through runnable_avg.
>>
>> The change in load-balance only affects migration type `migrate_util`.
>>
>> Suggested-by: Vincent Guittot <vincent.guittot@linaro.org>
>> Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
>>
> Tested on Intel Sapphire Rapids which has 2x56C/112T = 224 CPUs.
> The test tries to check if this is any impact on find_busiest_queue()
> so it was tested with cpufreq governor performance.
> The baseline is the 6.3 sched/core branch on top of
> Commit 67fff302fc445a ("sched/fair: Introduce SIS_CURRENT to wake up"),
> and compared to the code with current patch applied.
>
> In summary no obvious difference and some small improvements on tbench
> were observed so far:
many thanks for the test results!
Could you share the parameter lists you use for the individual tests?
This would make it easier to understand the results and rerun the tests
on similar machines.
[...]
next prev parent reply other threads:[~2023-05-05 18:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-06 15:50 [PATCH 0/1] sched: Consider CPU contention in frequency & load-balance busiest CPU selection Dietmar Eggemann
2023-04-06 15:50 ` [PATCH 1/1] " Dietmar Eggemann
2023-04-29 14:58 ` Peter Zijlstra
2023-05-03 17:13 ` Dietmar Eggemann
2023-05-04 15:23 ` Qais Yousef
2023-05-11 15:25 ` Dietmar Eggemann
2023-05-15 19:18 ` Qais Yousef
2023-05-03 16:08 ` Vincent Guittot
2023-05-04 17:11 ` Dietmar Eggemann
2023-05-05 8:22 ` Vincent Guittot
2023-05-05 18:16 ` Dietmar Eggemann
2023-05-05 7:10 ` Chen Yu
2023-05-05 18:02 ` Dietmar Eggemann [this message]
2023-05-07 2:19 ` Chen Yu
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=8276e5ce-b1f6-19e2-095b-abc6952bd1c7@arm.com \
--to=dietmar.eggemann@arm.com \
--cc=adharmap@quicinc.com \
--cc=kajetan.puchalski@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=morten.rasmussen@arm.com \
--cc=peterz@infradead.org \
--cc=qperret@google.com \
--cc=qyousef@layalina.io \
--cc=vdonnefort@google.com \
--cc=vincent.guittot@linaro.org \
--cc=yu.c.chen@intel.com \
/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;
as well as URLs for NNTP newsgroup(s).