From: Anjali K <anjalik@linux.ibm.com>
To: Christian Loehle <christian.loehle@arm.com>,
Qais Yousef <qyousef@layalina.io>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
Juri Lelli <juri.lelli@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Valentin Schneider <vschneid@redhat.com>,
Hongyan Xia <hongyan.xia2@arm.com>,
John Stultz <jstultz@google.com>,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7] sched: Consolidate cpufreq updates
Date: Mon, 25 Nov 2024 12:02:18 +0530 [thread overview]
Message-ID: <886aa016-a439-4981-892d-3e92df526f41@linux.ibm.com> (raw)
In-Reply-To: <a1cac0d3-c17d-478e-8a6b-40399a9428b6@linux.ibm.com>
On 19/10/24 00:02, Anjali K wrote:
>> Do you mind trying schedutil with a reasonable rate_limit_us, too?
> I think the schedutil governor is not working on my system because the cpu
> frequency shoots to the maximum (3.9GHz) even when the system is only 10%
> loaded.
> I ran stress-ng --cpu `nproc` --cpu-load 10.
> The mpstat command shows that the system is 10% loaded:
> 10:55:25 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
> 10:56:50 AM all 10.03 0.00 0.02 0.00 0.18 0.00 0.00 0.00 0.00 89.76
> But cpupower frequency-info showed that the system is at max frequency
> root@ltczz10:~# cpupower frequency-info
> <snipped>
> available cpufreq governors: conservative ondemand performance schedutil
> current policy: frequency should be within 2.30 GHz and 3.90 GHz.
> The governor "schedutil" may decide which speed to use
> within this range.
> current CPU frequency: 3.90 GHz (asserted by call to hardware)
> <snipped>
> This is not expected, right?
> I will work on finding out why the schedutil governor is not working on
> this system and get back.
Hi, I found that the schedutil governor is working on this system. I
concluded this because when I printed the util parameter passed in
get_next_freq() when running stress-ng --cpu `nproc` --cpu-load 10, the
util parameter was always 1024 ( equal to the cpu capacity) and so the
frequency gets set to the maximum as expected. Adding `--cpu-load-slice 10`
to the stress-ng commandline, I got lower util values and found that the
frequency is being set as per the system load as shown below:
+-------------+------------+------------+
| stress-ng | avg | run-to-run |
| load % | cpu freq | std dev% |
| | (Hz) | |
+-------------+------------+------------+
| 10% | 2.80 | 1.51 |
| 30% | 3.53 | 2.47 |
| 50% | 3.70 | 0.01 |
| 70% | 3.61 | 0.08 |
| 90% | 3.54 | 0.04 |
+-------------+------------+------------+
Note that the frequency range for this system is 2.3GHz - 3.9Ghz.
The results with the schedutil governor for the same set of benchmarks is
as follows. Each benchmark is run 3 times:
+------------------------------------------------------+--------------------+----------+--------+---------+------------+
| Benchmark | Baseline | Baseline |Baseline|Baseline |Regression% |
| | (6.10.0-rc1 tip | + patch | |+ patch | |
| | sched/core) | |stdev % | stdev % | |
+------------------------------------------------------+--------------------+----------+--------+---------+------------+
|Hackbench run duration (sec) | 1 | 1.01 | 1.60 | 1.80 | 0.69 |
|Lmbench simple fstat (usec) | 1 | 0.99 | 0.40 | 0.07 | -0.66 |
|Lmbench simple open/close (usec) | 1 | 0.99 | 0.01 | 0.04 | -0.51 |
|Lmbench simple read (usec) | 1 | 1 | 0.23 | 0.41 | -0.05 |
|Lmbench simple stat (usec) | 1 | 0.98 | 0.13 | 0.03 | -1.54 |
|Lmbench simple syscall (usec) | 1 | 0.99 | 0.89 | 0.69 | -0.59 |
|Lmbench simple write (usec) | 1 | 1 | 0.27 | 0.80 | 0 |
|Unixbench execl throughput (lps) | 1 | 1 | 0.44 | 0.13 | 0.17 |
|Unixbench Process Creation (lps) | 1 | 0.99 | 0.11 | 0.13 | -0.68 |
|Unixbench Shell Scripts (1 concurrent) (lpm) | 1 | 1 | 0.07 | 0.05 | 0.03 |
|Unixbench Shell Scripts (8 concurrent) (lpm) | 1 | 1 | 0.05 | 0.11 | -0.13 |
+------------------------------------------------------+--------------------+----------+--------+---------+------------+
I did not see any significant improvements/regressions on applying the patch.
I ignored the Stress-ng and Unixbench Pipebased Context Switching
benchmarks as they showed high run-to-run variation with the schedutil
governor (without applying the patch) of 10.68% and 12.5% respectively.
Thank you,
Anjali K
next prev parent reply other threads:[~2024-11-25 6:32 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-28 18:45 [PATCH v7] sched: Consolidate cpufreq updates Qais Yousef
2024-07-29 16:01 ` Metin Kaya
2024-08-01 12:22 ` Qais Yousef
2024-08-05 15:35 ` Christian Loehle
2024-08-09 1:13 ` Qais Yousef
2024-08-13 8:25 ` Vincent Guittot
2024-08-13 8:27 ` Vincent Guittot
2024-08-13 16:26 ` Christian Loehle
2024-08-13 16:43 ` Vincent Guittot
2024-08-13 16:56 ` Christian Loehle
2024-09-01 17:51 ` Qais Yousef
2024-09-02 12:30 ` Vincent Guittot
2024-09-02 12:35 ` Christian Loehle
2024-09-02 12:43 ` Vincent Guittot
2024-09-02 12:58 ` Qais Yousef
2024-09-02 13:34 ` Qais Yousef
2024-09-02 13:40 ` Christian Loehle
2024-09-02 13:36 ` Vincent Guittot
2024-09-02 20:43 ` Qais Yousef
2024-09-03 6:54 ` Vincent Guittot
2024-08-13 10:02 ` Vincent Guittot
2024-09-01 18:01 ` Qais Yousef
2024-09-03 12:48 ` Vincent Guittot
2024-09-11 20:34 ` Christian Loehle
2024-09-12 11:33 ` Rafael J. Wysocki
2025-02-09 22:34 ` Qais Yousef
2024-10-07 17:20 ` Anjali K
2024-10-08 9:56 ` Christian Loehle
2024-10-10 18:32 ` Christian Loehle
2024-10-18 18:32 ` Anjali K
2024-11-25 6:32 ` Anjali K [this message]
2025-02-09 22:33 ` Qais Yousef
2024-10-11 9:34 ` Christian Loehle
2025-02-09 22:41 ` Qais Yousef
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=886aa016-a439-4981-892d-3e92df526f41@linux.ibm.com \
--to=anjalik@linux.ibm.com \
--cc=bsegall@google.com \
--cc=christian.loehle@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=hongyan.xia2@arm.com \
--cc=jstultz@google.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=qyousef@layalina.io \
--cc=rafael@kernel.org \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.org \
--cc=vschneid@redhat.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