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: <20160118150102.GC7159@e106622-lin>
Date:	Mon, 18 Jan 2016 15:01:02 +0000
From:	Juri Lelli <juri.lelli@....com>
To:	Mark Brown <broonie@...nel.org>
Cc:	linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, peterz@...radead.org,
	vincent.guittot@...aro.org, robh+dt@...nel.org,
	mark.rutland@....com, linux@....linux.org.uk, sudeep.holla@....com,
	lorenzo.pieralisi@....com, catalin.marinas@....com,
	will.deacon@....com, morten.rasmussen@....com,
	dietmar.eggemann@....com
Subject: Re: [RFC PATCH v2 0/4] CPUs capacity information for heterogeneous
 systems

Hi Mark,

On 15/01/16 18:01, Mark Brown wrote:
> On Fri, Jan 08, 2016 at 02:09:28PM +0000, Juri Lelli wrote:
> 
> > Second version of this RFC proposes an alternative solution (w.r.t. v1) to the
> > problem of how do we init CPUs original capacity: we run a bogus benchmark (for
> > this RFC I simple stole int_sqrt from lib/ and I run that in a loop to perform
> > some integer computation, I'm sure there are better benchmarks around) on the
> > first cpu of each frequency domain (assuming no u-arch differences inside
> > domains), measure time to complete a fixed number of iterations and then
> > normalize results to SCHED_CAPACITY_SCALE (1024). I didn't spend much time in
> > polishing this up or thinking about a better benchmark, as this is an RFC and
> > I'd like discussion happening before we make this solution better
> > working/looking. However, surprisingly, results are not that bad already:
> 
> This approach looks good to me - certainly vastly preferable to putting
> the numbers into DT.
> 
> >  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
> 
> This actually seems to be pretty clean.
> 

Oh, maybe I was overly critic of my code then. :)

> >           - 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
> 
> This does come back to the question of how accurate the numbers need to
> be - is "good enough" fine?

Here we probably also have to account for the fact that numbers might
actually change from boot to boot. They might be good enough in average,
but you might have cases in which, for some reason, they turn out to be
far from usual values. Not that I see that happening much on my boxes,
but I guess it can happen.

Best,

- Juri