[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <001501d16b33$ff61d200$fe257600$@net>
Date: Fri, 19 Feb 2016 08:38:41 -0800
From: "Doug Smythies" <dsmythies@...us.net>
To: "'Stephane Gasparini'" <stephane.gasparini@...ux.intel.com>,
"'Mel Gorman'" <mgorman@...hsingularity.net>
Cc: "'Rafael Wysocki'" <rjw@...ysocki.net>,
"'Ingo Molnar'" <mingo@...nel.org>,
"'Peter Zijlstra'" <peterz@...radead.org>,
"'Matt Fleming'" <matt@...eblueprint.co.uk>,
"'Mike Galbraith'" <umgwanakikbuti@...il.com>,
"'Linux-PM'" <linux-pm@...r.kernel.org>,
"'LKML'" <linux-kernel@...r.kernel.org>,
"'Srinivas Pandruvada'" <srinivas.pandruvada@...ux.intel.com>
Subject: RE: [PATCH 1/1] intel_pstate: Increase hold-off time before busyness is scaled
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
Powered by blists - more mailing lists