From: "Jian-Min Liu (劉建旻)" <Jian-Min.Liu@mediatek.com>
To: "peterz@infradead.org" <peterz@infradead.org>
Cc: "dietmar.eggemann@arm.com" <dietmar.eggemann@arm.com>,
"mingo@kernel.org" <mingo@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"patrick.bellasi@matbug.net" <patrick.bellasi@matbug.net>,
"adharmap@quicinc.com" <adharmap@quicinc.com>,
"qais.yousef@arm.com" <qais.yousef@arm.com>,
"Jonathan JMChen (陳家明)" <Jonathan.JMChen@mediatek.com>,
"vdonnefort@google.com" <vdonnefort@google.com>,
"qperret@google.com" <qperret@google.com>,
"morten.rasmussen@arm.com" <morten.rasmussen@arm.com>,
"vincent.guittot@linaro.org" <vincent.guittot@linaro.org>
Subject: Re: [RFC PATCH 0/1] sched/pelt: Change PELT halflife at runtime
Date: Mon, 7 Nov 2022 09:41:29 +0000 [thread overview]
Message-ID: <64aedc190a7f3fc91967f42b2ad7ca244df63f89.camel@mediatek.com> (raw)
In-Reply-To: <YzVpqweg21yIn30A@hirez.programming.kicks-ass.net>
Hi,
On Thu, 2022-09-29 at 11:47 +0200, Peter Zijlstra wrote:
> 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?
>
Sorry for top-posting...
> 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.
Sorry that the data wasn't clear to understand. I try again with
absolute FPS numbers and some additional explanation as well as a
summary why we need to have the PELT halflife tunable a runtime.
HOK* 60FPS
+-------+-----------------------------------------+
| | avg. FPS | min. FPS | power |
+-------+--------+-------+-------+-------+--------+
|kernel | value |diff(%)| value |diff(%)| diff(%)|
+-------+--------+-------+-------+-------+--------+
|pelt_1 | 54.1 | 0.0% | 21.8 | 0.0% | 0.0% |
+-------+--------+-------+-------+-------+--------+
|pelt_2 | 56.9 | 5.2% | 29.2 | 34.0% | 2.2% |
+-------+--------+-------+-------+-------+--------+
|pelt_4 | 56.6 | 4.5% | 33.2 | 52.4% | 6.3% |
+-------+--------+-------+-------+-------+--------+
*Honour Of Kings, video game
Test methodology:
We choose 60FPS in the game setup. Android's systrace (similar to
ftrace) then provides the real FPS from which we take the average and
minimum value.
Sorry, but we can't share absolute numbers for power from our test
device since this is still considered sensitive information.
FHD 60fps video recording
+-------+-----------------------------------------+
| | avg. FPS | min. FPS | power |
+-------+--------+-------+-------+-------+--------+
|kernel | value |diff(%)| value |diff(%)| diff(%)|
+-------+--------+-------+-------+-------+--------+
|pelt_1 | 60.0 | 0.0% | 60.0 | 0.0% | 0.0% |
+-------+--------+-------+-------+-------+--------+
|pelt_4 | 60.0 | 0.0% | 60.0 | 0.0% | 2.1% |
+-------+--------+-------+-------+-------+--------+
To summarize, we need a smaller PELT halflife to reach higher avg. FPS
and min. FPS values for video gaming to achieve a smoother game-play
experience even when it comes with slightly higher power consumption.
Especially the improvement in min. FPS is important here to minimize
situations in which the game otherwise would stutter.
Since not all use cases profit from this behaviour (e.g. video
recording) the PELT halflife should be tunable at runtime.
prev parent reply other threads:[~2022-11-07 9:41 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-29 5:54 Dietmar Eggemann
2022-08-29 5:54 ` [RFC PATCH 1/1] sched/pelt: Introduce PELT multiplier Dietmar Eggemann
2022-08-29 8:08 ` Peter Zijlstra
2022-08-29 10:02 ` Peter Zijlstra
2022-08-29 10:13 ` Vincent Guittot
2022-08-29 14:23 ` Quentin Perret
2022-08-29 14:34 ` Peter Zijlstra
2022-08-29 15:31 ` Quentin Perret
2022-08-29 15:48 ` Quentin Perret
2022-09-02 7:53 ` Dietmar Eggemann
2022-09-02 8:45 ` Peter Zijlstra
2022-09-06 5:49 ` Vincent Guittot
2022-09-08 6:50 ` Dietmar Eggemann
2022-09-02 7:53 ` Dietmar Eggemann
2022-09-02 8:45 ` Peter Zijlstra
2022-09-20 14:07 ` [RFC PATCH 0/1] sched/pelt: Change PELT halflife at runtime Jian-Min Liu
2022-09-28 17:09 ` Dietmar Eggemann
2022-09-29 9:47 ` Peter Zijlstra
2022-09-29 11:07 ` Dietmar Eggemann
2022-09-29 11:10 ` Kajetan Puchalski
2022-09-29 11:21 ` Peter Zijlstra
2022-09-29 14:41 ` Kajetan Puchalski
2022-10-03 22:57 ` Wei Wang
2022-10-04 9:33 ` Dietmar Eggemann
2022-10-05 16:57 ` Wei Wang
2022-11-07 13:41 ` Peter Zijlstra
2022-11-08 19:48 ` Qais Yousef
2022-11-09 15:49 ` Peter Zijlstra
2022-11-10 13:25 ` Qais Yousef
2023-02-07 10:29 ` Dietmar Eggemann
2023-02-09 16:16 ` Vincent Guittot
2023-02-17 13:54 ` Dietmar Eggemann
2023-02-20 13:54 ` Vincent Guittot
2023-02-21 9:29 ` Vincent Guittot
2023-02-22 20:28 ` Dietmar Eggemann
2023-03-01 10:24 ` Vincent Guittot
2023-02-22 20:13 ` Dietmar Eggemann
2023-03-02 19:36 ` Dietmar Eggemann
2023-02-20 10:13 ` Peter Zijlstra
2023-02-20 13:39 ` Vincent Guittot
2023-02-23 15:37 ` Qais Yousef
2023-03-01 10:39 ` Vincent Guittot
2023-03-01 17:24 ` Qais Yousef
2023-03-02 8:00 ` Vincent Guittot
2023-03-02 19:39 ` Dietmar Eggemann
2023-03-06 19:11 ` Qais Yousef
2023-03-07 13:22 ` Vincent Guittot
2023-03-11 16:55 ` Qais Yousef
2023-03-23 16:29 ` Dietmar Eggemann
2023-04-03 14:45 ` Qais Yousef
2023-04-06 15:58 ` Dietmar Eggemann
2023-04-11 17:51 ` Qais Yousef
2022-11-09 15:18 ` Lukasz Luba
2022-11-10 11:16 ` Dietmar Eggemann
2022-11-10 13:05 ` Peter Zijlstra
2022-11-10 14:59 ` Dietmar Eggemann
2022-11-10 17:51 ` Peter Zijlstra
2022-11-30 18:14 ` Dietmar Eggemann
2022-12-01 13:37 ` Kajetan Puchalski
2022-11-10 12:45 ` Kajetan Puchalski
2022-11-07 9:41 ` Jian-Min Liu (劉建旻) [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=64aedc190a7f3fc91967f42b2ad7ca244df63f89.camel@mediatek.com \
--to=jian-min.liu@mediatek.com \
--cc=Jonathan.JMChen@mediatek.com \
--cc=adharmap@quicinc.com \
--cc=dietmar.eggemann@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=morten.rasmussen@arm.com \
--cc=patrick.bellasi@matbug.net \
--cc=peterz@infradead.org \
--cc=qais.yousef@arm.com \
--cc=qperret@google.com \
--cc=vdonnefort@google.com \
--cc=vincent.guittot@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®