[RFC PATCH 2/8] Documentation: arm: define DT cpu capacity bindings

[Mark Rutland]

On Tue, Dec 15, 2015 at 01:39:51PM +0000, Mark Brown wrote:
> On Tue, Dec 15, 2015 at 12:22:38PM +0000, Juri Lelli wrote:
> > > So then why isn't it adequate to just have things like the core types in
> > > there and work from there?  Are we really expecting the tuning to be so
> > > much better than it's possible to come up with something that's so much
> > > better on the scale that we're expecting this to be accurate that it's
> > > worth just jumping straight to magic numbers?
> 
> > I take your point here that having fine grained values might not really
> > give us appreciable differences (that is also why I proposed the
> > capacity-scale in the first instance), but I'm not sure I'm getting what
> > you are proposing here.
> 
> Something like the existing solution for arm32.
> 
> >  static const struct cpu_efficiency table_efficiency[] = {
> >  	{"arm,cortex-a15", 3891},
> >  	{"arm,cortex-a7",  2048},
> >  	{NULL, },
> >  };
> 
> > When clock-frequency property is defined in DT, we try to find a match
> > for the compatibility string in the table above and then use the
> > associate number to compute the capacity. Are you proposing to have
> > something like this for arm64 as well?
> 
> > BTW, the only info I could find about those numbers is from this thread
> 
> It was discussed in some other thread when I was sending the equivalent
> stuff for arm64 (I never got round to finishing it off due to issues
> with Catalin and Will being concerned about the specific numbers).
> Vincent confirmed that the numbers came from the (IIRC) DMIPS/MHz
> numbers that ARM publish for the cores.  I'd independently done the same
> thing for arm64.  It would probably help to put comments in there with
> the base numbers before scaling, or just redo the table in terms of the
> raw numbers.
> 
> This is, of course, an example of my concerns about magic number
> configuration.
> 
> > If I understand how that table was created, how do we think we will
> > extend it in the future to allow newer core types (say we replicate this
> > solution for arm64)?  It seems that we have to change it, rescaling
> > values, each time we have a new core on the market. How can we come up
> > with relative numbers, in the future, comparing newer cores to old ones
> > (that might be already out of the market by that time)?
> 
> It doesn't seem particularly challenging to add new numbers to the table
> (and add additional properties to select on) TBH.  We can either rescale
> by hand in the table when adding entries, script it as part of the
> kernel build or do it at runtime (as the arm32 code already does to an
> extent based on the particular set of cores we find).  What difficulties
> do you see with this?
> 
> This is something that seems like an advantage to me - we can just
> replace everything at any point, we're not tied to trusting the golden
> benchmark someone did (or tweaked) if we come up with a better
> methodology later on.

I really don't want to see a table of magic numbers in the kernel.

The relative performance and efficiency of cores will vary depending on
uArch-specific configuration (e.g. sizing of L1/L2 caches) in addition
to general uArch differences, and integration too (e.g. if the memory
system gives priority to one cluster over another for whatever reason).
I've heard of pseudo-heterogeneous platforms with different
configuration of the same uArch across clusters.

We also don't necessarily have the CPU clock frequencies, or the ability
to scale them. Maybe we simply give up in that case, though.

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.

Thanks,
Mark.