Date: Tue, 15 Dec 2015 15:36:37 +0000
From: Juri Lelli <juri.lelli@arm.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Mark Brown <broonie@kernel.org>, Rob Herring <robh@kernel.org>,
        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,
        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, 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@lixom.net>,
        Gregory CLEMENT <gregory.clement@free-electrons.com>,
        Paul Walmsley <paul@pwsan.com>,
        Linus Walleij <linus.walleij@linaro.org>, Chen-Yu Tsai <wens@csie.org>,
        Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Subject: Re: [RFC PATCH 2/8] Documentation: arm: define DT cpu capacity
 bindings
Message-ID: <20151215153637.GJ16007@e106622-lin>
References: <20151210153004.GA26758@sirena.org.uk>
 <20151210175820.GE14571@e106622-lin>
 <20151211174940.GQ5727@sirena.org.uk>
 <20151214123616.GC3308@e106622-lin>
 <20151214165928.GV5727@sirena.org.uk>
 <20151215122238.GG16007@e106622-lin>
 <20151215133951.GY5727@sirena.org.uk>
 <20151215140135.GI31299@leverpostej>
 <20151215142458.GI16007@e106622-lin>
 <20151215145050.GA7041@leverpostej>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20151215145050.GA7041@leverpostej>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3212
Lines: 75

On 15/12/15 14:50, Mark Rutland wrote:
> On Tue, Dec 15, 2015 at 02:24:58PM +0000, Juri Lelli wrote:
> > Hi Mark,
> 
> Hi Juri,
> 
> > On 15/12/15 14:01, Mark Rutland wrote:
> > > I really don't want to see a table of magic numbers in the kernel.
> > 
> > Doesn't seem to be a clean and scalable solution to me either. It is not
> > easy to reconfigure when new core types come around, as I don't think
> > relative data is always present or easy to derive, and it exposes some
> > sort of centralized global information where everyone is compared
> > against everyone.
> 
> I'm also concerned that it will be difficult to curate this to avoid
> deceptive marketing numbers. These may not reflect reality.
> 

Right.

> > Where the DT solution is inherently per platform: no need to expose
> > absolute values and no problems with knowing data regarding old core
> > types.
> 
> The DT approach certainly avoids tying the kernel to a given idea of
> particular microarchitectures.
> 
> > > If we cannot rely on external information, and want this information to
> > > be derived by the kernel, then we need to perform some dynamic
> > > benchmark. That would work for future CPUs the kernel knows nothing
> > > about yet, and would cater for the pseudo-heterogeneous cases too.
> > 
> > I've actually experimented a bit with this approch already, but I wasn't
> > convinced of its viability. It is true that we remove the burden of
> > coming up with default values from user/integrator, but I'm pretty sure
> > we will end up discussing endlessly about which particular benchmark to
> > pick 
> 
> Regardless of which direction we go there will be endless discussion as
> to the benchmark. As Mark pointed out, that happened in the case of the
> table, and it's happening now for the DT approach.
> 
> I think we agree that if this is something we can change later (i.e. we
> don't rely on an external oracle like DT) the particular benchmark
> matters less, as that can be changed given evidence of superiority.
> 

True, and in fact we already only point out suggestions for sensitive
benchmarks. I don't think we want to tie ourselves to any particular
one. And I think not having a particular benchmark implementation as
part of the solution will help changing our minds afterwards.

> > and the fact that it impacts on boot time and such.
> 
> I was under the impression that the kernel already did RAID algorithm
> benchmarking as part of the boot process. Maybe we can find a set of
> similarly brief benchmarks.
> 

Yeah, it's certainly doable, but I'm not really yet seeing what we gain
with this additional complexity. Also, AFAIK boot time is one important
metric for the mobile market (while it is less crucial for systems with
RAID configurations?) and we are going to add overhead there. Stability
of default values is probably another factor here, where you could be
rebooting your phone in many different conditions from time to time.

Best,

- Juri
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/