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
next prev 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: linkBe 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.