Messages in this thread | | | Date | Mon, 18 Dec 2023 09:19:04 +0100 | Subject | Re: [PATCH 0/4] sched: cpufreq: Remove uclamp max-aggregation | From | Dietmar Eggemann <> |
| |
On 08/12/2023 02:52, Qais Yousef wrote:
[...]
> === > > This patch is based on remove margins series [1] and data is collected it > against it as a baseline. > > Testing on pixel 6 with mainline(ish) kernel
How is the Pixel6 configured in terms of per-policy rate_limit_us and response_time_ms ? Is this the now default 2ms and whatever the systems calculates for response_time_ms ?
Pixel6 is still a slow switching device, rigth?
root 297 2 1 08:58:01 ? 00:00:13 [sugov:0] root 298 2 0 08:58:01 ? 00:00:03 [sugov:4] root 299 2 1 08:58:01 ? 00:00:05 [sugov:6]
> == > > Speedometer browser benchmark > > | baseline | 1.25 headroom | patch | patch + 1.25 headroom > -------+-----------+---------------+-----------+--------------------- > score | 108.03 | 135.72 | 108.09 | 137.47 > -------+-----------+---------------+-----------+--------------------- > power | 1204.75 | 1451.79 | 1216.17 | 1484.73 > -------+-----------+---------------+-----------+---------------------
What's the difference between baseline & 1.25 headroom. IMHO, we have:
static inline unsigned long map_util_perf(unsigned long util) { return util + (util >> 2); }
on baseline?
By patch you refer to the whole patch-set + [1]?
And I assume 'patch + 1.25 headroom' is 'response_time_ms' tuned to reach 1.25 ?
[...]
| |