4 ms·

Is it easy to automatically and exclusively pin an application to some cores? Firefox automatically gets assigned two cores, and no other work is allowed there?

Is it easy to automatically and exclusively pin an application to some cores? Firefox automatically gets assigned two cores, and no other work is allowed there? I know I theoretically have the ability to set affinity, but have never explored it. Are there performance gotchas (outside of losing all core access)? Perhaps performance could even see minor improvement?

insanitybit 3y ago
Yeah it's fairly straightforward. You can boot your OS such that it won't schedule work on a set of cores unless you explicitly tell it to, which ensures isolation. You just have to pass the core numbers in. Otherwise it's possible to do it all in userland but it's not as reliable since a new process could spawn and you'd have to handle its affinity - it's way easier to just do the process core boot flags. > Are there performance gotchas (outside of losing all core access)? Depends on the workload and how the program is built. If you need to run tons of different processes concurrently (the 'user desktop' use case) it is not great. If your concurrency model requires creating hundreds of threads (Java, for most of the time it existed) it may not work well, especially if the threads don't have an even distribution of work (so you may see increased tail latencies). And, of course, if you have 8 cores but you isolate a workload to 6, you've just lost 2 cores that could have been used. > Perhaps performance could even see minor improvement? Considerable improvement, potentially. Less CPU synchronization means fewer L3 flushes, you'll get fewer context switches since your scheduler won't need to try to schedule other threads onto your core, fewer TLB flushes (relevant for kPTI/Meltdown mitigations), etc. If you lean into this approach you can get best in class throughput.

4 ms·

Is it easy to automatically and exclusively pin an application to some cores? Firefox automatically gets assigned two cores, and no other work is allowed there?

by fbdab103 3y ago

insanitybit 3y ago
Yeah it's fairly straightforward. You can boot your OS such that it won't schedule work on a set of cores unless you explicitly tell it to, which ensures isolation. You just have to pass the core numbers in. Otherwise it's possible to do it all in userland but it's not as reliable since a new process could spawn and you'd have to handle its affinity - it's way easier to just do the process core boot flags. > Are there performance gotchas (outside of losing all core access)? Depends on the workload and how the program is built. If you need to run tons of different processes concurrently (the 'user desktop' use case) it is not great. If your concurrency model requires creating hundreds of threads (Java, for most of the time it existed) it may not work well, especially if the threads don't have an even distribution of work (so you may see increased tail latencies). And, of course, if you have 8 cores but you isolate a workload to 6, you've just lost 2 cores that could have been used. > Perhaps performance could even see minor improvement? Considerable improvement, potentially. Less CPU synchronization means fewer L3 flushes, you'll get fewer context switches since your scheduler won't need to try to schedule other threads onto your core, fewer TLB flushes (relevant for kPTI/Meltdown mitigations), etc. If you lean into this approach you can get best in class throughput.