logoalt Hacker News

somatyesterday at 9:07 PM1 replyview on HN

"Introduced a mechanism to manage CPU cores with different speeds in the scheduler. The sysctl(8) variable "hw.blockcpu" takes a sequence of 4 letters: S (for SMT), P (regular performance CPU), E (efficient CPU, generally 80% to 50% as fast), and L (lethargic CPU) which are even slower. Set this to select CPUs to kick out of the scheduler (SL by default). Currently works on amd64 and arm64."

I have to admit I am not entirely convinced about the merit of having slow cores on the cpu at all(big/little architecture). You don't want your tasks to be scheduled on them. And even for background tasks shouldn't it be better to have them complete faster for less power? To say nothing about what if they have different features. what happens when a process that wants to use cpu feature X(avx512?) gets scheduled on a cpu without X?

Openbsd took the quick and dirty shotgun approach here in disabling the slow cores. But is there even a good heuristic for scheduling jobs on them? The only thing I can think of is some sort complicated mechanism of putting manual tags in the executable or thread. A "this process is suitable for slow cores" sort of thing.

I was reading about this on on the lists, apparently a naive scheduler puts a process wherever and some new big/little systems have very slow little cores. This really hit recompiling code hard.


Replies

creatonezyesterday at 10:01 PM

> And even for background tasks shouldn't it be better to have them complete faster for less power

Race to idle is only clearly beneficial for tasks that have a clear start and end. If a background task is sustained, responds to unpredictable events, or does small amounts of work and wakes frequently, the CPU's boost logic won't solve your energy usage problem.

> To say nothing about what if they have different features. what happens when a process that wants to use cpu feature X(avx512?) gets scheduled on a cpu without X

This idea has been proposed in the past, but isn't actually used on x86-64 or ARM. E-cores have the same instruction set as P-cores, so there's no risk of running into an invalid CPU instruction.

Truly heterogeneous instruction sets may come back in the future, though. So be on your toes.