From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932355AbcARTZr (ORCPT ); Mon, 18 Jan 2016 14:25:47 -0500 Received: from mail-pa0-f47.google.com ([209.85.220.47]:34552 "EHLO mail-pa0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932283AbcARTZo (ORCPT ); Mon, 18 Jan 2016 14:25:44 -0500 Subject: Re: [RFC PATCH v2 0/4] CPUs capacity information for heterogeneous systems To: Juri Lelli References: <1452262172-31861-1-git-send-email-juri.lelli@arm.com> <56994D87.6000709@linaro.org> <20160118151316.GD7159@e106622-lin> Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, peterz@infradead.org, vincent.guittot@linaro.org, robh+dt@kernel.org, mark.rutland@arm.com, linux@arm.linux.org.uk, sudeep.holla@arm.com, lorenzo.pieralisi@arm.com, catalin.marinas@arm.com, will.deacon@arm.com, morten.rasmussen@arm.com, dietmar.eggemann@arm.com, broonie@kernel.org From: Steve Muckle X-Enigmail-Draft-Status: N1110 Message-ID: <569D3C35.5070703@linaro.org> Date: Mon, 18 Jan 2016 11:25:41 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20160118151316.GD7159@e106622-lin> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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