linux-kernel - Re: [PATCH 1/1] intel_pstate: Increase hold-off time before busyness is scaled

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <9E20D36B-1323-41AA-969F-3D2DD5021701@linux.intel.com>
Date:	Wed, 24 Feb 2016 17:19:48 +0100
From:	Stephane Gasparini <stephane.gasparini@...ux.intel.com>
To:	Doug Smythies <dsmythies@...us.net>
Cc:	Mel Gorman <mgorman@...hsingularity.net>,
	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 Doug


> On Feb 19, 2016, at 5:38 PM, Doug Smythies <dsmythies@...us.net> wrote:
> 
> 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.
> I’m not talking about using average p-state in the scaled_busy computation.

I’m talking adding the output of the PID (the number of pstate to ad or subtract)
to the average pstate rather than adding this to the current p-sate.

The current p-state is in some situation not reflecting the reality as the 
current p-state can be imposed by a "linked CPU". This is the case when you have a
thread migration on "linked CPU" that was not loaded. Its current P-State will be low
while its average p-state will reflect the activity of the "linked CPU".

I will not claim this is a perfect solution, but this combined to the topology 
awareness of the scheduler is helping to take better decision.

> 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
> 
> 
—
Steph