From: Juri Lelli <juri.lelli@arm.com>
To: Steve Muckle <steve.muckle@linaro.org>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.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: [PATCH v3 0/6] CPUs capacity information for heterogeneous systems
Date: Tue, 9 Feb 2016 17:40:52 +0000 [thread overview]
Message-ID: <20160209174052.GT11415@e106622-lin> (raw)
In-Reply-To: <56BA221D.1030907@linaro.org>
On 09/02/16 09:30, Steve Muckle wrote:
> On 02/09/2016 02:37 AM, Juri Lelli wrote:
> >> I'm still concerned that there's no way to obtain optimal boot time on a
> >> > heterogeneous system. Either the dynamic benchmarking is enabled, adding
> >> > 1 sec, or the benchmarking is skipped, and task distribution on the
> >> > heterogeneous CPUs is determined by the platform's CPU numbering and
> >> > chance, potentially impacting performance nondeterministically until
> >> > userspace sets the correct capacity values via sysfs.
> >> >
> >> > I believe you tested the impact on boot time of using equal capacity
> >> > values and saw little difference. I'm wondering though, what was the CPU
> >> > numbering on that target?
> >> >
> >
> > My targets (Juno and TC2) had big cluster on 1,2 and little on the
> > remaining cpus. Why do you think this might matter?
>
> There's a natural bias in the scheduler AFAIK towards lower-numbered
> CPUs since they are typically scanned in numerically ascending order. So
> when all capacities are initially defaulted to be the same I think
> you'll be more likely to use the lower numbered CPUs.
>
> I'd be curious what the performance penalty is on a b.L system where the
> lowest numbered CPUs are small. I don't have such a target but maybe
> it's possible to compare booting just with bigs vs just with littles, at
> least until userspace intializes and a script can bring up the others,
> which is the same point at which capacities could be properly set. That
> would give something of an upper bound.
>
Yeah. I could run some tests along this line. It should give us a rough
idea about how much we are leaving on the table.
> > Anyway, IMHO boot time performance is not what we are targeting here, so
> > I wouldn't be too worried about this particular point.
>
> It may not be the most important thing but it is a factor worth
> considering - as mentioned earlier there are applications where boot
> time is critical such as automotive. It seems unfortunate that actual
> performance may be left on the table due to (IMO anyway) a tenuous
> concern over DT semantics. But it looks like that may just be my
> position :/ .
>
Don't get me wrong Steve. I agree with you and I tried to defend the DT
approach as much as I could. I still think that it is the best solution
(much more cleaner and simpler), but it seems that there is no way we
can make it happen. Or has this discussion we are having changed things
in the meantime? :)
Thanks,
- Juri
prev parent reply other threads:[~2016-02-09 17:40 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-03 11:59 [PATCH v3 0/6] CPUs capacity information for heterogeneous systems Juri Lelli
2016-02-03 11:59 ` [PATCH v3 1/6] ARM: initialize cpu_scale to its default Juri Lelli
2016-02-03 11:59 ` [PATCH v3 2/6] drivers/cpufreq: implement init_cpu_capacity_default() Juri Lelli
2016-02-03 21:04 ` Vincent Guittot
2016-02-04 9:36 ` Morten Rasmussen
2016-02-04 12:03 ` Vincent Guittot
2016-02-04 12:16 ` Juri Lelli
2016-02-04 12:35 ` Vincent Guittot
2016-02-04 14:13 ` Juri Lelli
2016-02-04 15:44 ` Vincent Guittot
2016-02-04 15:46 ` Vincent Guittot
2016-02-05 9:30 ` Juri Lelli
2016-02-09 15:54 ` Dietmar Eggemann
2016-02-10 14:25 ` Juri Lelli
2016-02-03 11:59 ` [PATCH v3 3/6] arm: Enable dynamic CPU capacity initialization Juri Lelli
2016-02-03 11:59 ` [PATCH v3 4/6] arm64: " Juri Lelli
2016-02-08 12:28 ` Dietmar Eggemann
2016-02-08 13:13 ` Mark Brown
2016-02-08 13:41 ` Dietmar Eggemann
2016-02-03 11:59 ` [PATCH v3 5/6] arm: add sysfs cpu_capacity attribute Juri Lelli
2016-02-03 11:59 ` [PATCH v3 6/6] arm64: " Juri Lelli
2016-02-05 17:19 ` Dietmar Eggemann
2016-02-05 17:49 ` Juri Lelli
2016-02-08 23:59 ` [PATCH v3 0/6] CPUs capacity information for heterogeneous systems Steve Muckle
2016-02-09 10:37 ` Juri Lelli
2016-02-09 17:30 ` Steve Muckle
2016-02-09 17:40 ` Juri Lelli [this message]
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=20160209174052.GT11415@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=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=steve.muckle@linaro.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 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 read-only IMAP folder(s) and NNTP newsgroup(s).