linux-kernel - Re: [RFC PATCH v2 0/4] CPUs capacity information for heterogeneous systems

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160119105941.GA28845@e104818-lin.cambridge.arm.com>
Date:	Tue, 19 Jan 2016 10:59:42 +0000
From:	Catalin Marinas <catalin.marinas@....com>
To:	Vincent Guittot <vincent.guittot@...aro.org>
Cc:	Juri Lelli <juri.lelli@....com>,
	Mark Rutland <mark.rutland@....com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Mark Brown <broonie@...nel.org>,
	Will Deacon <will.deacon@....com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Dietmar Eggemann <dietmar.eggemann@....com>,
	Rob Herring <robh+dt@...nel.org>,
	Steve Muckle <steve.muckle@...aro.org>,
	Sudeep Holla <sudeep.holla@....com>,
	Morten Rasmussen <morten.rasmussen@....com>,
	LAK <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC PATCH v2 0/4] CPUs capacity information for heterogeneous
 systems

On Mon, Jan 18, 2016 at 05:42:58PM +0100, Vincent Guittot wrote:
> On 18 January 2016 at 17:30, Juri Lelli <juri.lelli@....com> wrote:
> > On 18/01/16 17:13, Vincent Guittot wrote:
> >> On 18 January 2016 at 16:13, Juri Lelli <juri.lelli@....com> wrote:
> >> > On 15/01/16 11:50, Steve Muckle wrote:
> >> >> On 01/08/2016 06:09 AM, Juri Lelli wrote:
> >> >> >  2. Dynamic profiling at boot (v2)
> >> >> >
> >> >> >     pros: - does not require a standardized definition of capacity
> >> >> >           - cannot be incorrectly tuned (once benchmark is fixed)
> >> >> >           - does not require user/integrator work
> >> >> >
> >> >> >     cons: - not easy to come up with a clean solution, as it seems interaction
> >> >> >             with several subsystems (e.g., cpufreq) is required
> >> >> >           - not easy to agree upon a single benchmark (that has to be both
> >> >> >             representative and simple enough to run at boot)
> >> >> >           - numbers might (and do) vary from boot to boot
> >> >>
> >> >> An important additional con that was mentioned earlier IIRC was the
> >> >> additional boot time required for the benchmark.
> >> >
> >> > Right. I forgot about that.
> >> >
> >> >> Perhaps there could be
> >> >> a kernel command line argument to bypass the benchmark if it is known
> >> >> that predetermined values will be provided via sysfs later?
> >> >>
> >> >
> >> > This might work, yes.
> >>
> >> Instead of command line, I prefer to use DT.

I fully agree. Command line doesn't scale with multiple CPUs, at most an
option to bypass the benchmark (though we could just skip it when the DT
values are present).

> >> Can't we use something similar to what is currently done in arm arch
> >> for the early stage of the boot ? We don't have to provide performance
> >> value for which it's difficult to find a consensus on how to define it
> >> and which benchmark should be used. We use the micro arch and the
> >> frequency of the core to define a relative capacity. This give us a
> >> relatively good idea of the capacity of each core.
> >
> > I'm not sure I understand what you are proposing. arm arch is currently
> > based on having static hardcoded data (efficiency values). But, this has
> > already been NACKed for arm64 during last review of this RFC.
> >
> > Are you proposing something different?
> 
> No, i'm proposing to use it at boot time until the dynamic profiling
> gives better value.
> We don't have to set any new properties.
> IIRC, It was nacked because it was of static hardcoded value that was
> not always reflecting the best accurate capacity of a system. IMHO,
> it's not that far from reality so can't this be used as an
> intermediate step while waiting for dynamic profiling ?

My nack for hard-coded values still stands since this is not just about
the microarchitecture (MIDR) but how the CPUs are integrated with the
SoC, additional caches, memory latency, maximum clock frequency (or you
rely on DT again to get this information and scale the initial CPU
capacity/efficiency accordingly). MIDR does not capture SoC details.

Two questions:

1. How is the boot time affected by the benchmark?
2. How is the boot time affected by considering all the CPUs the same?

My preference is for DT and sysfs (especially useful for
development/tuning) but I'm not opposed to a boot-time benchmark if
people insist on it. If the answer to point 2 is "insignificant", we
could as well defer the capacity setting to user space (sysfs).

-- 
Catalin