linux-kernel - Re: [RFC PATCH 0/1] sched/pelt: Change PELT halflife at runtime

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 23 Feb 2023 15:37:00 +0000
From:   Qais Yousef <qyousef@...alina.io>
To:     Vincent Guittot <vincent.guittot@...aro.org>
Cc:     Dietmar Eggemann <dietmar.eggemann@....com>,
        Peter Zijlstra <peterz@...radead.org>,
        Kajetan Puchalski <kajetan.puchalski@....com>,
        Jian-Min Liu <jian-min.liu@...iatek.com>,
        Ingo Molnar <mingo@...nel.org>,
        Morten Rasmussen <morten.rasmussen@....com>,
        Vincent Donnefort <vdonnefort@...gle.com>,
        Quentin Perret <qperret@...gle.com>,
        Patrick Bellasi <patrick.bellasi@...bug.net>,
        Abhijeet Dharmapurikar <adharmap@...cinc.com>,
        Qais Yousef <qais.yousef@....com>,
        linux-kernel@...r.kernel.org,
        Jonathan JMChen <jonathan.jmchen@...iatek.com>
Subject: Re: [RFC PATCH 0/1] sched/pelt: Change PELT halflife at runtime

On 02/09/23 17:16, Vincent Guittot wrote:

> I don't see how util_est_faster can help this 1ms task here ? It's
> most probably never be preempted during this 1ms. For such an Android
> Graphics Pipeline short task, hasn't uclamp_min been designed for and
> a better solution ?

uclamp_min is being used in UI and helping there. But your mileage might vary
with adoption still.

The major motivation behind this is to help things like gaming as the original
thread started. It can help UI and other use cases too. Android framework has
a lot of context on the type of workload that can help it make a decision when
this helps. And OEMs can have the chance to tune and apply based on the
characteristics of their device.

> IIUC how util_est_faster works, it removes the waiting time when
> sharing cpu time with other tasks. So as long as there is no (runnable
> but not running time), the result is the same as current util_est.
> util_est_faster makes a difference only when the task alternates
> between runnable and running slices.
> Have you considered using runnable_avg metrics in the increase of cpu
> freq ? This takes into the runnable slice and not only the running
> time and increase faster than util_avg when tasks compete for the same
> CPU

Just to understand why we're heading into this direction now.

AFAIU the desired outcome to have faster rampup time (and on HMP faster up
migration) which both are tied to utilization signal.

Wouldn't make the util response time faster help not just for rampup, but
rampdown too?

If we improve util response time, couldn't this mean we can remove util_est or
am I missing something?

Currently we have util response which is tweaked by util_est and then that is
tweaked further by schedutil with that 25% margin when maping util to
frequency.

I think if we can allow improving general util response time by tweaking PELT
HALFLIFE we can potentially remove util_est and potentially that magic 25%
margin too.

Why the approach of further tweaking util_est is better?

Recently phoronix reported that schedutil behavior is suboptimal and I wonder
if the response time is contributing to that

	https://www.phoronix.com/review/schedutil-quirky-2023

Cheers

--
Qais Yousef