lkml.org 
[lkml]   [2023]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [RFC PATCH 5/7] sched/schedutil: Add a new tunable to dictate response time
    From
    On 28/08/2023 01:32, Qais Yousef wrote:

    [...]

    > @@ -427,6 +427,23 @@ This governor exposes only one tunable:
    > The purpose of this tunable is to reduce the scheduler context overhead
    > of the governor which might be excessive without it.
    >
    > +``respone_time_ms``
    > + Amount of time (in milliseconds) required to ramp the policy from
    > + lowest to highest frequency. Can be decreased to speed up the
    > + responsiveness of the system, or increased to slow the system down in
    > + hope to save power. The best perf/watt will depend on the system
    > + characteristics and the dominant workload you expect to run. For
    > + userspace that has smart context on the type of workload running (like
    > + in Android), one can tune this to suite the demand of that workload.
    > +
    > + Note that when slowing the response down, you can end up effectively
    > + chopping off the top frequencies for that policy as the util is capped
    > + to 1024. On HMP systems where some CPUs have a capacity less than 1024,

    HMP isn't used in mainline AFAIK. IMHO, the term `asymmetric CPU
    capacity` systems is used.

    [...]

    > @@ -59,6 +61,45 @@ static DEFINE_PER_CPU(struct sugov_cpu, sugov_cpu);
    >
    > /************************ Governor internals ***********************/
    >
    > +static inline u64 sugov_calc_freq_response_ms(struct sugov_policy *sg_policy)
    > +{
    > + int cpu = cpumask_first(sg_policy->policy->cpus);
    > + unsigned long cap = capacity_orig_of(cpu);
    > +
    > + return approximate_runtime(cap);
    > +}

    I can see the potential issue of schedutil being earlier initialized
    than the `max frequency scaling of cpu_capacity_orig` happens in
    drivers/base/arch_topology.c.

    So the response_time_ms setup for a little CPU on Juno-r0 wouldn't
    happen on cpu_capacity_orig = 446 -> 26ms but on on the raw capacity
    value from dt:

    capacity-dmips-mhz = <578>

    So I would expect to see t = 32ms * ln(1 - 578/1024)/ln(0.5) = 38ms instead.

    We have a similar dependency between `max frequency scaled
    cpu_capacity_orig` and the EM setup code.

    [...]

    \
     
     \ /
      Last update: 2023-09-06 23:13    [W:3.913 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site