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:

quoted

quoted

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?

quoted

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.

quoted

 static const struct cpu_efficiency table_efficiency[] = {
 	{"arm,cortex-a15", 3891},
 	{"arm,cortex-a7",  2048},
 	{NULL, },
 };

quoted

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?

quoted

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.

quoted

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.