linux-kernel - Re: [RFC PATCH v2 0/4] CPUs capacity information for heterogeneous systems

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <569D3C35.5070703@linaro.org>
Date:	Mon, 18 Jan 2016 11:25:41 -0800
From:	Steve Muckle <steve.muckle@...aro.org>
To:	Juri Lelli <juri.lelli@....com>
Cc:	linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, peterz@...radead.org,
	vincent.guittot@...aro.org, robh+dt@...nel.org,
	mark.rutland@....com, linux@....linux.org.uk, sudeep.holla@....com,
	lorenzo.pieralisi@....com, catalin.marinas@....com,
	will.deacon@....com, morten.rasmussen@....com,
	dietmar.eggemann@....com, broonie@...nel.org
Subject: Re: [RFC PATCH v2 0/4] CPUs capacity information for heterogeneous
 systems

On 01/18/2016 07:13 AM, Juri Lelli wrote:
>> DT solves these issues and would be the perfect place for this - we are
>> > defining the compute capacity of a CPU which is a property of the
>> > hardware. However there are a couple things forcing us to compromise.
>> > One is that the amount and detail of information required to adequately
>> > capture the computational abilities of a CPU across all possible
>> > workloads seem onerous to collect and enumerate. The second is that even
>> > if we were willing to undertake that, CPU vendors probably won't be
>> > forthcoming with that information.
>> > 
>
> You mean because they won't publish performance data of their hw?

More specific things like IPC and other architectural details that could
comprise a precise physical definition of a CPU that would meet the
ideal goals of a device tree definition.

> But we already use per platform normalized values (as you are proposing
> below). So that a platform to platform comparison doesn't make sense.

Yeah I'm just advocating for that strategy here.

cheers,
Steve