>Not sure why it would be discouraged pinToCPU (at least in Nim) just sets scheduling affinity, but does not hard-allocate like the Linux isolcpus boot paramet

>Not sure why it would be discouraged pinToCPU (at least in Nim) just sets scheduling affinity, but does not hard-allocate like the Linux isolcpus boot parameter.."pin" makes it sound more powerful than it is. It is more like POSIX `nice` than POSIX `mlock`. But also, `nice` exists for a reason. Your agenda might be to do something as much as possible on a Little core which is indeed potentially useful. pinToCPU takes a cpu number and you can usually know from that number whether it is Big or Little. The real concern may be that the OS has a more global picture of system activity than any one program..and so discourage "second guessing" the scheduler. OTOH, the OS probably does not have a picture of how important timely completion of any particular thing is - honestly that could almost be end-user-provided data (much like there is a `nice` command). A lot of the time people motivate affinity just as a "use the same L1/L2 cache" for "absolute max perf", and in that sense you may be getting better perf, but over fewer cores (only the big ones) or you may not do the ahead of time work to map out big-little CPU numbers. Scheduling is also very OS-specific. So, reasoning about what Y you get when you ask for X can also be tricky in any OS-portable setting. Sometimes things are "so complicated" that people "who know" just discourage those who do not. My inclination is instead to explain what it can/cannot/does/does not do better rather than discourage its use.