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

From: Peter Zijlstra <peterz@infradead.org>
To: Jian-Min Liu <jian-min.liu@mediatek.com>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ingo Molnar <mingo@kernel.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Morten Rasmussen <morten.rasmussen@arm.com>,
	Vincent Donnefort <vdonnefort@google.com>,
	Quentin Perret <qperret@google.com>,
	Patrick Bellasi <patrick.bellasi@matbug.net>,
	Abhijeet Dharmapurikar <adharmap@quicinc.com>,
	Qais Yousef <qais.yousef@arm.com>,
	linux-kernel@vger.kernel.org,
	Jonathan JMChen <jonathan.jmchen@mediatek.com>
Subject: Re: [RFC PATCH 0/1] sched/pelt: Change PELT halflife at runtime
Date: Thu, 29 Sep 2022 11:47:23 +0200	[thread overview]
Message-ID: <YzVpqweg21yIn30A@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <0f82011994be68502fd9833e499749866539c3df.camel@mediatek.com>

Because it messes up the order in which people normally read text.
Why is top-posting such a bad thing?
Top-posting.
What is the most annoying thing in e-mail?

On Tue, Sep 20, 2022 at 10:07:59PM +0800, Jian-Min Liu wrote:
> 
> Update some test data in android phone to support switching PELT HL 
> is helpful functionality.
> 
> We switch runtime PELT HL during runtime by difference scenario e.g.
> pelt8 in playing game, pelt32 in camera video. Support runntime
> switching PELT HL is flexible for different workloads.
> 
> the below table show performance & power data points: 
> 
> ---------------------------------------------------------------------
> --|                      | 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.

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.

> -----------------------------------------------------------------------
> 
> 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.