linux-kernel - Re: [PATCH 6/8] cpufreq/schedutil: sum per-sched class utilization

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <56E9B016.9080306@linaro.org>
Date:	Wed, 16 Mar 2016 12:12:22 -0700
From:	Steve Muckle <steve.muckle@...aro.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Michael Turquette <mturquette@...libre.com>, rjw@...ysocki.net,
	linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
	Juri.Lelli@....com, morten.rasmussen@....com,
	dietmar.eggemann@....com, vincent.guittot@...aro.org,
	Michael Turquette <mturquette+renesas@...libre.com>
Subject: Re: [PATCH 6/8] cpufreq/schedutil: sum per-sched class utilization

On 03/16/2016 11:36 AM, Peter Zijlstra wrote:
> On Wed, Mar 16, 2016 at 11:20:45AM -0700, Steve Muckle wrote:
>> On 03/16/2016 12:38 AM, Peter Zijlstra wrote:
>>> Somewhere in the giant discussions I mentioned that we should be looking
>>> at a CPPC like interface and pass {min,max} tuples to the cpufreq
>>> selection thingy.
>>>
>>> In that same discussion I also mentioned that we must compute min as the
>>> hard dl reservation, but that for max we can actually use the avg dl +
>>> avg rt + avg cfs.
>>>
>>> That way there is far more room for selecting a sensible frequency.
>>
>> Doesn't the above min/max policy mean that the platform will likely
>> underserve the task load? If avg dl+rt+cfs represents our best estimate
>> of the work to be done, I would think that should be the min.
> 
> Can't be the min, avg_dl might (and typically will be) must lower than
> the worst case utilization estimates.
> 
> However if we use that as our min, peaks in DL utilization will not
> complete, because we run at too low a frequency.

Doesn't that mean the max (if one is specified) should also use hard dl?
I.e. hard dl + rt + cfs.

> Therefore, the min must be given by our worst case utilization
> reservation, not by the actual avg consumed.

Ok sure. My concern was more about the platform potentially ignoring the
CFS and RT capacity requests. So given the point about DL bw I'd think
the min would then be hard dl + rt + cfs.