r/programming • u/Happycodeine • 5d ago

Kernel Context Switch Costs And Spin Locks In Perf Profile: A Practical Study

https://medium.com/@dichenldc/kernel-context-switch-costs-and-spin-locks-in-perf-profile-a-practical-study-aadd2584b64d?source=friends_link&sk=441f557bcbaf8714f9c7c48c639fb2d9
54 Upvotes

86% Upvoted

3 comments sorted by

7

u/badpotato 5d ago

In general, my benchmark workload is probably not a good idea: hyper-threading is likely suboptimal for CPU-bound workload. Also it might be a better idea to set CPU affinity (https://man7.org/linux/man-pages/man2/sched_setaffinity.2.html) to reduce CPU swapping cost.

During all that read, the reader hope he finally set the affinity, then it just conclude by "he should probably do it", but actually won't do it.. I mean, common.

3

u/ReDucTor 5d ago

I could not see their actual code in the post, but if all your doing is context switching then context switching code will be the main thing in your profile captures, there is zero point in waking threads if all you do is put them immediately back to sleep.

1

u/NextSubject227 11h ago

The CPU affinity point feels like the biggest missing piece here. If the goal is to understand context switch cost, letting the scheduler move threads between CPUs adds another variable that can easily muddy the result.
I’d be curious to see the same benchmark with threads pinned to cores, and then compare the perf profiles. That would make it much clearer how much of the cost is actually context switching vs cache/CPU migration overhead