From: "Doug Smythies" <dsmythies@telus.net>
To: 'Stephane Gasparini' <stephane.gasparini@linux.intel.com>,
'Mel Gorman' <mgorman@techsingularity.net>
Cc: 'Rafael Wysocki' <rjw@rjwysocki.net>,
'Ingo Molnar' <mingo@kernel.org>,
'Peter Zijlstra' <peterz@infradead.org>,
'Matt Fleming' <matt@codeblueprint.co.uk>,
'Mike Galbraith' <umgwanakikbuti@gmail.com>,
'Linux-PM' <linux-pm@vger.kernel.org>,
'LKML' <linux-kernel@vger.kernel.org>,
'Srinivas Pandruvada' <srinivas.pandruvada@linux.intel.com>
Subject: RE: [PATCH 1/1] intel_pstate: Increase hold-off time before busyness is scaled
Date: Fri, 19 Feb 2016 08:38:41 -0800 [thread overview]
Message-ID: <001501d16b33$ff61d200$fe257600$@net> (raw)
In-Reply-To: <E45553FF-63B3-4E5B-92A0-B5B00353F6F8@linux.intel.com>
Hi Steph,
On 2016.02.19 03:12 Stephane Gasparini wrote:
>
> The issue you are reporting looks like one we improved on android by using
> the average pstate instead of using the last requested pstate
>
> We know that this is improving the ffmpeg encoding performance when using the
> load algorithm.
>
> see patch attached
>
> This patch is only applied on get_target_pstate_use_cpu_load however you can give
> it a try on get_target_pstate_use_performance
Yes, that type of patch works on the load based approach.
However, I do not think it works on the performance based approach. Why not?
Well, and if I understand correctly, follow the math and you end up with:
scaled_busy = 100%
scaled_busy = (aperf * 100% / mperf) * (max_pstate / * ((aperf * max_pstate) / mperf))
... Doug
next prev parent reply other threads:[~2016-02-19 16:38 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-18 11:11 [PATCH 1/1] intel_pstate: Increase hold-off time before busyness is scaled Mel Gorman
2016-02-18 19:43 ` Rafael J. Wysocki
2016-02-18 21:09 ` Doug Smythies
2016-02-19 10:49 ` Mel Gorman
2016-02-23 14:04 ` Mel Gorman
2016-02-18 23:29 ` Pandruvada, Srinivas
2016-02-18 23:33 ` Rafael J. Wysocki
2016-02-19 11:11 ` Stephane Gasparini
2016-02-19 16:38 ` Doug Smythies [this message]
2016-02-24 16:19 ` Stephane Gasparini
2016-02-25 19:51 ` Doug Smythies
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='001501d16b33$ff61d200$fe257600$@net' \
--to=dsmythies@telus.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=matt@codeblueprint.co.uk \
--cc=mgorman@techsingularity.net \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rjw@rjwysocki.net \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=stephane.gasparini@linux.intel.com \
--cc=umgwanakikbuti@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.