> > 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.
