• Lukasz Luba's avatar
    sched/fair: Take thermal pressure into account while estimating energy · 489f1645
    Lukasz Luba authored
    Energy Aware Scheduling (EAS) needs to be able to predict the frequency
    requests made by the SchedUtil governor to properly estimate energy used
    in the future. It has to take into account CPUs utilization and forecast
    Performance Domain (PD) frequency. There is a corner case when the max
    allowed frequency might be reduced due to thermal. SchedUtil is aware of
    that reduced frequency, so it should be taken into account also in EAS
    estimations.
    
    SchedUtil, as a CPUFreq governor, knows the maximum allowed frequency of
    a CPU, thanks to cpufreq_driver_resolve_freq() and internal clamping
    to 'policy::max'. SchedUtil is responsible to respect that upper limit
    while setting the frequency through CPUFreq drivers. This effective
    frequency is stored internally in 'sugov_policy::next_freq' and EAS has
    to predict that value.
    
    In the existing code the raw value of arch_scale_cpu_capacity() is used
    for clamping the returned CPU utilization from effective_cpu_util().
    This patch fixes issue with too big single CPU utilization, by introducing
    clamping to the allowed CPU capacity. The allowed CPU capacity is a CPU
    capacity reduced by thermal pressure raw value.
    
    Thanks to knowledge about allowed CPU capacity, we don't get too big value
    for a single CPU utilization, which is then added to the util sum. The
    util sum is used as a source of information for estimating whole PD energy.
    To avoid wrong energy estimation in EAS (due to capped frequency), make
    sure that the calculation of util sum is aware of allowed CPU capacity.
    
    This thermal pressure might be visible in scenarios where the CPUs are not
    heavily loaded, but some other component (like GPU) drastically reduced
    available power budget and increased the SoC temperature. Thus, we still
    use EAS for task placement and CPUs are not over-utilized.
    Signed-off-by: default avatarLukasz Luba <lukasz.luba@arm.com>
    Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: default avatarVincent Guittot <vincent.guittot@linaro.org>
    Reviewed-by: default avatarDietmar Eggemann <dietmar.eggemann@arm.com>
    Link: https://lore.kernel.org/r/20210614191128.22735-1-lukasz.luba@arm.com
    489f1645
fair.c 303 KB