10:18:01 <nikolam> 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. 
10:19:28 <nikolam> Or is it solely app's / userland task to optimise for efficient cores presence or should kernel take into account efficient cores, too 
15:33:31 <sommerfeld> 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.
16:08:49 <sommerfeld> 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.  
17:07:45 <gitomat> [illumos-gate] 16350 SHA1 may produce incorrect hashes if given a 2^29 byte input -- Bill Sommerfeld <sommerfeld⊙ho>
19:09:05 <richlowe> in theory, processor groups are the abstraction, in practice they're not nearly the right shape anymore
19:09:24 <richlowe> as far as P/E-aware dispatch
19:10:38 <richlowe> I think people familiar with the extent of AMD's architecture have thought about it more deeply than I have
21:45:50 <richlowe> I have been thinking ~since whenever I said that about what power-aware schedule/dispatch in this sense would even look like
21:46:08 <richlowe> what's your cue that a given thread would benefit from a P-core? 
21:47:21 <richlowe> or do you just let threads bubble up onto the P cores, where iff they're regularly runnable on E we give them P?
21:48:27 <richlowe> 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