re: cpu temperature readings

[matthew green <mrg%eterna.com.au@localhost>]

> > though NetBSD's cpu selection algorithm doesn't (yet anyway) really
> > understand processors like this.
>
> The scheduler did use first cores first, with performance cores
> using low cpu numbers, they should be utilized first but not
> necessarily for the important workloads.
>
> It now handles big.little configurations independent of cpu numbers,
> but probably only on arm.

our scheduler has a fast/slow CPU method only, so it handles
"HT" by saying the non-1st sibling is slow, and the 1st one
attached is fast, and for big.little/dynamiq it just marks
the big cores as fast and little cores as slow.  it then
prefers fast cores over slow cores, and it will typically
select lower cpu numbers once within the fast/slow zone.

eg, on rk3399, cpu4 and cpu5 are used first for most tasks
as they're the big cores, and cpu0 ends up getting a lot of
random interrupts, and cpu1-3 are idle unless you're using
more than 3 cores of CPU.

this means that the 3-level speed provided by the newer intel
client cpus is not handled by our code, and i believe it
means it will not give up and not attempt any special and
will thus just end up using cpu numbers.

i had a look at converting the "bool cpu_is_slow" in cpu_data
into an integer, but i didn't get far enough understanding
all the current uses to properly know where to start.  would
be great if someone where to have a look at this.

one hack to make thing work "sort of OK", would be to allow
this to have one thread of the e-cores as fast, and both the
other thread and the p-cores as slow.


.mrg.