lkml.org 
[lkml]   [2023]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 0/4] sched: cpufreq: Remove uclamp max-aggregation
From
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 ?

[...]

\
 
 \ /
  Last update: 2023-12-18 09:21    [W:0.269 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site