All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Muckle <steve.muckle@linaro.org>
To: Juri Lelli <juri.lelli@arm.com>
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
Subject: Re: [RFC PATCH v2 0/4] CPUs capacity information for heterogeneous systems
Date: Mon, 18 Jan 2016 11:25:41 -0800	[thread overview]
Message-ID: <569D3C35.5070703@linaro.org> (raw)
In-Reply-To: <20160118151316.GD7159@e106622-lin>

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

WARNING: multiple messages have this Message-ID (diff)
From: steve.muckle@linaro.org (Steve Muckle)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v2 0/4] CPUs capacity information for heterogeneous systems
Date: Mon, 18 Jan 2016 11:25:41 -0800	[thread overview]
Message-ID: <569D3C35.5070703@linaro.org> (raw)
In-Reply-To: <20160118151316.GD7159@e106622-lin>

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

  parent reply	other threads:[~2016-01-18 19:25 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-08 14:09 [RFC PATCH v2 0/4] CPUs capacity information for heterogeneous systems Juri Lelli
2016-01-08 14:09 ` Juri Lelli
2016-01-08 14:09 ` [RFC PATCH v2 1/4] ARM: initialize cpu_scale to its default Juri Lelli
2016-01-08 14:09   ` Juri Lelli
2016-01-08 14:09   ` Juri Lelli
2016-01-08 14:09 ` [RFC PATCH v2 2/4] drivers/cpufreq: implement init_cpu_capacity_default() Juri Lelli
2016-01-08 14:09   ` Juri Lelli
2016-01-08 14:09 ` [RFC PATCH v2 3/4] arm: Enable dynamic CPU capacity initialization Juri Lelli
2016-01-08 14:09   ` Juri Lelli
2016-01-08 14:09 ` [RFC PATCH v2 4/4] arm64: " Juri Lelli
2016-01-08 14:09   ` Juri Lelli
2016-01-15 18:01 ` [RFC PATCH v2 0/4] CPUs capacity information for heterogeneous systems Mark Brown
2016-01-15 18:01   ` Mark Brown
2016-01-18 15:01   ` Juri Lelli
2016-01-18 15:01     ` Juri Lelli
2016-01-15 19:50 ` Steve Muckle
2016-01-15 19:50   ` Steve Muckle
2016-01-18 15:13   ` Juri Lelli
2016-01-18 15:13     ` Juri Lelli
2016-01-18 16:13     ` Vincent Guittot
2016-01-18 16:13       ` Vincent Guittot
2016-01-18 16:30       ` Juri Lelli
2016-01-18 16:30         ` Juri Lelli
2016-01-18 16:42         ` Vincent Guittot
2016-01-18 16:42           ` Vincent Guittot
2016-01-18 17:08           ` Juri Lelli
2016-01-18 17:08             ` Juri Lelli
2016-01-18 17:23             ` Vincent Guittot
2016-01-18 17:23               ` Vincent Guittot
2016-01-19 10:59           ` Catalin Marinas
2016-01-19 10:59             ` Catalin Marinas
2016-01-19 11:23             ` Juri Lelli
2016-01-19 11:23               ` Juri Lelli
2016-01-19 14:29               ` Juri Lelli
2016-01-19 14:29                 ` Juri Lelli
2016-01-19 19:48                 ` Steve Muckle
2016-01-19 19:48                   ` Steve Muckle
2016-01-19 21:10                   ` Mark Brown
2016-01-19 21:10                     ` Mark Brown
2016-01-20 10:22                     ` Juri Lelli
2016-01-20 10:22                       ` Juri Lelli
2016-01-18 19:25     ` Steve Muckle [this message]
2016-01-18 19:25       ` Steve Muckle
2016-01-19 15:05 ` Peter Zijlstra
2016-01-19 15:05   ` Peter Zijlstra
2016-01-19 17:50   ` Mark Brown
2016-01-19 17:50     ` Mark Brown
2016-01-20 10:25     ` Juri Lelli
2016-01-20 10:25       ` Juri Lelli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=569D3C35.5070703@linaro.org \
    --to=steve.muckle@linaro.org \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=morten.rasmussen@arm.com \
    --cc=peterz@infradead.org \
    --cc=robh+dt@kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=vincent.guittot@linaro.org \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.