devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Juri Lelli <juri.lelli@arm.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Sai Gurrappadi <sgurrappadi@nvidia.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	LAK <linux-arm-kernel@lists.infradead.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Morten Rasmussen <morten.rasmussen@arm.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Mark Brown <broonie@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>,
	Maxime Ripard <maxime.ripard@free-electrons.com>,
	Olof Johansson <olof@l>
Subject: Re: [PATCH v4 2/8] Documentation: arm: define DT cpu capacity bindings
Date: Mon, 21 Mar 2016 11:49:56 +0000	[thread overview]
Message-ID: <20160321114956.GD12319@e106622-lin> (raw)
In-Reply-To: <CAKfTPtDP3zMR+zbvvqJCBvJ5r44do8NS03wC7pAejxPd0zHTMA@mail.gmail.com>

Hi Vincent,

On 21/03/16 12:09, Vincent Guittot wrote:
> On 21 March 2016 at 11:53, Juri Lelli <juri.lelli@arm.com> wrote:
> > Hi Sai,
> >
> > On 18/03/16 10:49, Sai Gurrappadi wrote:
> >> Hi Juri,
> >>
> >> On 03/18/2016 07:24 AM, Juri Lelli wrote:
> >>
> >> <snip>
> >>
> >> > +
> >> > +==========================================
> >> > +2 - CPU capacity definition
> >> > +==========================================
> >> > +
> >> > +CPU capacity is a number that provides the scheduler information about CPUs
> >> > +heterogeneity. Such heterogeneity can come from micro-architectural differences
> >> > +(e.g., ARM big.LITTLE systems) or maximum frequency at which CPUs can run
> >> > +(e.g., SMP systems with multiple frequency domains). Heterogeneity in this
> >> > +context is about differing performance characteristics; this binding tries to
> >> > +capture a first-order approximation of the relative performance of CPUs.
> >>
> >> Any reason why this capacity number is not dynamically generated based on the
> >> max frequency for each CPU? The DT property would then instead specify just
> >> the micro-architectural differences between the CPU types.
> >>
> >
> > I'm not sure I clearly understand your question, so I'll try to
> > reiterate it.
> >
> > Are you asking why we don't dynamically profile the system, at boot for
> > example, to get this number? Or do you ask why this number couldn't be
> > only describing micro-arch differences (so, if I get it right, we should
> > then multiply it by max freq to get the capacity of a CPU)?
> >
> > We already played with the first option (please refer to v2 and v3), but
> > we ended up agreeing that dynamic profiling adds overhead to the boot
> > process (while a DT approach can provide information to speed up boot)
> > and it is in general not repeatable/reliable (as numbers can vary from
> > boot to boot for different reasons).
> >
> > The second option I think can be feasible, but I'm not sure what we gain
> > in practice. We will still need to specify a per-platform number, right?
> 
> So could we use dt binding like dhrystone = <xyz> (with a unit like
> DMIPS/Mhz)  which can then be combined with OPP table to gives a
> 1st-order approximation of each CPU capacity ?
> 

But we'll still need to normalize this w.r.t the highest score we get on
a specific platform, right? And while we are at normalizing it, it is
probably simpler if we keep the frequency component as part of the
number, IMHO. But, maybe keeping the frequency component separate is
more acceptable from a DT binding perspective?

Thanks,

- Juri

  reply	other threads:[~2016-03-21 11:49 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-18 14:24 [PATCH v4 0/8] CPUs capacity information for heterogeneous systems Juri Lelli
2016-03-18 14:24 ` [PATCH v4 1/8] ARM: initialize cpu_scale to its default Juri Lelli
2016-03-18 14:24 ` [PATCH v4 2/8] Documentation: arm: define DT cpu capacity bindings Juri Lelli
2016-03-18 17:49   ` Sai Gurrappadi
     [not found]     ` <56EC3F9E.4050209-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-03-21 10:53       ` Juri Lelli
2016-03-21 11:09         ` Vincent Guittot
2016-03-21 11:49           ` Juri Lelli [this message]
2016-03-21 12:12             ` Mark Brown
     [not found]               ` <20160321121210.GQ2566-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-03-21 17:24                 ` Juri Lelli
2016-03-21 17:51                   ` Mark Brown
     [not found]                     ` <20160321175112.GY2566-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-03-22  9:50                       ` Juri Lelli
2016-03-21 19:20         ` Sai Gurrappadi
2016-03-20  1:15   ` Rob Herring
2016-03-21 11:39     ` Juri Lelli
2016-03-18 14:24 ` [PATCH v4 3/8] arm: parse cpu capacity from DT Juri Lelli
2016-03-18 14:24 ` [PATCH v4 4/8] arm, dts: add TC2 cpu capacity information Juri Lelli
2016-03-18 14:24 ` [PATCH v4 5/8] arm64: parse cpu capacity from DT Juri Lelli
2016-03-18 14:24 ` [PATCH v4 6/8] arm64, dts: add Juno cpu capacity information Juri Lelli
2016-03-18 14:24 ` [PATCH v4 7/8] arm: add sysfs cpu_capacity attribute Juri Lelli
2016-03-18 14:24 ` [PATCH v4 8/8] arm64: " 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=20160321114956.GD12319@e106622-lin \
    --to=juri.lelli@arm.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dietmar.eggemann@arm.com \
    --cc=galak@codeaurora.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --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=maxime.ripard@free-electrons.com \
    --cc=morten.rasmussen@arm.com \
    --cc=olof@l \
    --cc=pawel.moll@arm.com \
    --cc=peterz@infradead.org \
    --cc=robh+dt@kernel.org \
    --cc=sgurrappadi@nvidia.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).