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]

Message-ID: <b9caf0c7-8f61-f5e3-b299-3ae5b76d8b63@arm.com>
Date:   Thu, 29 Sep 2022 13:07:16 +0200
From:   Dietmar Eggemann <dietmar.eggemann@....com>
To:     Peter Zijlstra <peterz@...radead.org>,
        Jian-Min Liu <jian-min.liu@...iatek.com>
Cc:     Ingo Molnar <mingo@...nel.org>,
        Vincent Guittot <vincent.guittot@...aro.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 29/09/2022 11:47, Peter Zijlstra wrote:

[...]

>> ---------------------------------------------------------------------
>> --|                      | PELT
>> halflife                                |
>> |                      |----------------------------------------------|
>> |                      |       32      |       16      |       8      |
>> |                      |----------------------------------------------|
>> |                      | avg  min  avg | avg  min  avg | avg  min  avg|
>> | Scenarios            | fps  fps  pwr | fps  fps  pwr | fps  fps  pwr|
>> |---------------------------------------------------------------------|
>> | HOK game 60fps       | 100  100  100 | 105 *134* 102 | 104 *152* 106|
>> | HOK game 90fps       | 100  100  100 | 101 *114* 101 | 103 *129* 105|
>> | HOK game 120fps      | 100  100  100 | 102 *124* 102 | 105 *134* 105|
> 
> You have your min and avg fps columns mixed up, your min cannot be larger
> than avg.
> 
> Also, with min fps mostly above the actual screen fps, who cares. And
> seriously 120fps on a phone !?!? for worse power usage! you gotta be
> kidding me.

I agree that since we don't know what 100% at 32 means its unclear what
problem gets actually solved here by running with 16 or 8.

> And I googled this game; it is some top-down tactical thing with
> real-time combat (as opposed to turn-based) (DOTA like I suppose),
> 60 fps locked should be plenty fine.
> 
>> | FHD video rec. 60fps | 100  100  100 | n/a  n/a  n/a | 100  100  103|
>> | Camera snapshot      | 100  100  100 | n/a  n/a  n/a | 100  100  102|
> 
> Mostly I think you've demonstrated that none of this is worth it.

I assume Jian-Min added those two lines to demonstrate that they would
need the run-time switch.

>> -----------------------------------------------------------------------
>>
>> HOK ... Honour Of Kings, Video game
>> FHD ... Full High Definition
>> fps ... frame per second
>> pwr ... power consumption
>>
>> table values are in %
> 
> Oh... that's bloody insane; that's why none of it makes sense.
> 
> 
> How is any of that an answer to:
> 
>   "They want; I want an explanation of what exact problem is fixed how ;-)"
> 
> This is just random numbers showing poking the number has some effect;
> it has zero explaination of why poking the number changes the workload
> and if that is in fact the right way to go about solving that particular
> issue.

Jian-Min, would you be able to show real numbers in comparison to the
chosen fps here? And explain what the problem is which gets solved. What
is the effect of this higher min fps values when running 16 or 8? And
why is the default 32 not sufficient here?