[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fa2f15b1-1602-4fd0-80ff-9d33303b7b5a@arm.com>
Date: Tue, 8 Oct 2024 10:56:02 +0100
From: Christian Loehle <christian.loehle@....com>
To: Anjali K <anjalik@...ux.ibm.com>, Qais Yousef <qyousef@...alina.io>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Viresh Kumar <viresh.kumar@...aro.org>, Ingo Molnar <mingo@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Vincent Guittot <vincent.guittot@...aro.org>,
Juri Lelli <juri.lelli@...hat.com>
Cc: Steven Rostedt <rostedt@...dmis.org>,
Dietmar Eggemann <dietmar.eggemann@....com>, Ben Segall
<bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
Valentin Schneider <vschneid@...hat.com>, Hongyan Xia
<hongyan.xia2@....com>, John Stultz <jstultz@...gle.com>,
linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7] sched: Consolidate cpufreq updates
On 10/7/24 18:20, Anjali K wrote:
> Hi, I tested this patch to see if it causes any regressions on bare-metal power9 systems with microbenchmarks.
> The test system is a 2 NUMA node 128 cpu powernv power9 system. The conservative governor is enabled.
> I took the baseline as the 6.10.0-rc1 tip sched/core kernel.
> No regressions were found.
>
> +------------------------------------------------------+--------------------+----------+
> | Benchmark | Baseline | Baseline |
> | | (6.10.0-rc1 tip | + patch |
> | | sched/core) | |
> +------------------------------------------------------+--------------------+----------+
> |Hackbench run duration (sec) | 1 | 1.01 |
> |Lmbench simple fstat (usec) | 1 | 0.99 |
> |Lmbench simple open/close (usec) | 1 | 1.02 |
> |Lmbench simple read (usec) | 1 | 1 |
> |Lmbench simple stat (usec) | 1 | 1.01 |
> |Lmbench simple syscall (usec) | 1 | 1.01 |
> |Lmbench simple write (usec) | 1 | 1 |
> |stressng (bogo ops) | 1 | 0.94 |
> |Unixbench execl throughput (lps) | 1 | 0.97 |
> |Unixbench Pipebased Context Switching throughput (lps)| 1 | 0.94 |
> |Unixbench Process Creation (lps) | 1 | 1 |
> |Unixbench Shell Scripts (1 concurrent) (lpm) | 1 | 1 |
> |Unixbench Shell Scripts (8 concurrent) (lpm) | 1 | 1.01 |
> +------------------------------------------------------+--------------------+----------+
>
> Thank you,
> Anjali K
>
The default CPUFREQ_DBS_MIN_SAMPLING_INTERVAL is still to have 2 ticks between
cpufreq updates on conservative/ondemand.
What is your sampling_rate setting? What's your HZ?
Interestingly the context switch heavy benchmarks still show -6% don't they?
Do you mind trying schedutil with a reasonable rate_limit_us, too?
Regards,
Christian
Powered by blists - more mailing lists