Is there any impelmentation of Biglittle differentiation between fast and efficient CPU cores , or is it CPU "optimising" it by itself at a runtime? Having in mind ryzen 4 and 4c are funcionally identical and P and E cores on Intel are not.

Or is it solely app's / userland task to optimise for efficient cores presence or should kernel take into account efficient cores, too

nikolam: I believe the usual approach for this adds a userland component that shuffles CPU affinity. On illumos you could define separate processor sets (see psrset(8)) and define your own policy for when to shuffle processes between sets.

nikolam: I partly take that back - there are some linux-kernel-only approaches to this. but this would likely best be prototyped with a userland policy piece looking at kstats and performance counters to identify which threads should be moved where.

[illumos-gate] 16350 SHA1 may produce incorrect hashes if given a 2^29 byte input -- Bill Sommerfeld <sommerfeld⊙ho>

in theory, processor groups are the abstraction, in practice they're not nearly the right shape anymore

as far as P/E-aware dispatch

I think people familiar with the extent of AMD's architecture have thought about it more deeply than I have

I have been thinking ~since whenever I said that about what power-aware schedule/dispatch in this sense would even look like

what's your cue that a given thread would benefit from a P-core?

or do you just let threads bubble up onto the P cores, where iff they're regularly runnable on E we give them P?

someone would need to survey the state of the art and then figure out a data structure (presumably pg a v2) that allowed for it, and reasonable extensions of it