aboutsummaryrefslogtreecommitdiff
path: root/MAINTAINERS
diff options
context:
space:
mode:
authorVincent Guittot <vincent.guittot@linaro.org>2018-10-19 15:14:11 +0200
committerVincent Guittot <vincent.guittot@linaro.org>2018-10-22 12:09:30 +0200
commit95c32aa323ad31bbc3fbb12dad63231c3a96b0bf (patch)
treebf91c635c7e2298398571056fab632e2febbe0b6 /MAINTAINERS
parentb5018c0b46919d084a52738aa43f29bcbf6553f6 (diff)
sched/fair: update scale invariance of PELTsched-invariance
The current implementation of load tracking invariance scales the contribution with current frequency and uarch performance (only for utilization) of the CPU. One main result of this formula is that the figures are capped by current capacity of CPU. Another one is that the load_avg is not invariant because not scaled with uarch. The util_avg of a periodic task that runs r time slots every p time slots varies in the range : U * (1-y^r)/(1-y^p) * y^i < Utilization < U * (1-y^r)/(1-y^p) with U is the max util_avg value = SCHED_CAPACITY_SCALE At a lower capacity, the range becomes: U * C * (1-y^r')/(1-y^p) * y^i' < Utilization < U * C * (1-y^r')/(1-y^p) with C reflecting the compute capacity ratio between current capacity and max capacity. so C tries to compensate changes in (1-y^r') but it can't be accurate. Instead of scaling the contribution value of PELT algo, we should scale the running time. The PELT signal aims to track the amount of computation of tasks and/or rq so it seems more correct to scale the running time to reflect the effective amount of computation done since the last update. In order to be fully invariant, we need to apply the same amount of running time and idle time whatever the current capacity. Because running at lower capacity implies that the task will run longer, we have to ensure that the same amount of idle time will be apply when system becomes idle and no idle time has been "stolen". But reaching the maximum utilization value (SCHED_CAPACITY_SCALE) means that the task is seen as an always-running task whatever the capacity of the CPU (even at max compute capacity). In this case, we can discard this "stolen" idle times which becomes meaningless. In order to achieve this time scaling, a new clock_pelt is created per rq. The increase of this clock scales with current capacity when something is running on rq and synchronizes with clock_task when rq is idle. With this mecanism, we ensure the same running and idle time whatever the current capacity. This also enables to simplify the pelt algorithm by removing all reference of uarch and frequency and applying the same contribution to utilization and loads. Then, the scaling is done only once per update of clock (update_rq_clock_task()) instead of during each update of sched_entities and cfs/rt/dl_rq of the rq like the current implementation. The responsivness of PELT is improved when CPU is not running at max capacity with this new algorithm. I have put below some examples of duration to reach some typical load values according to the capacity of the CPU with current implementation and with this patch. Util (%) max capacity half capacity(mainline) half capacity(w/ patch) 972 (95%) 138ms not reachable 276ms 486 (47.5%) 30ms 138ms 60ms 256 (25%) 13ms 32ms 26ms On my hikey (octo ARM platform) with schedutil governor, the time to reach max OPP when starting from a null utilization, decreases from 223ms with current scale invariance down to 121ms with the new algorithm. For this test, I have enable arch_scale_freq for arm64. Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Diffstat (limited to 'MAINTAINERS')
0 files changed, 0 insertions, 0 deletions