Home/ Questions/Q 7600423
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-30T22:54:21+00:00

It is possible to pin a process to a specific set of CPU cores

  • 0

It is possible to pin a process to a specific set of CPU cores using sched_setaffinity() call. The manual page says:

   Restricting a process to run on a single CPU also avoids the
   performance cost caused by the cache invalidation that occurs when a process
   ceases to execute on one CPU and then recommences execution on a different
   CPU.

Which is almost an obvious thing (or not?). What is not that obvious to me is this –

Does pinning LWPs to a specific CPU or an SMP node reduces a cache coherency bus traffic? For example, since a process is running pinned, other CPUs should not modify its private memory, thus only CPUs that are part of the same SMP node should stay cache-coherent.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    There should be no CPU socket-to-socket coherency traffic for the pinned process case you describe. Modern Xeon platforms implement snoop filtering in the chipset. The snoop filter indicates when a remote socket cannot have the cache line in question, thus avoiding the need to send cache invalidate messages to that socket.

    You can measure this for yourself. Xeon processors implement a large variety of cache statistic counters. You can read the counters in your own code with the rdpmc instruction or just use a product like VTune. FYI, using rdpmc is very precise, but a little tricky since you have to initially set a bit in CR4 to allow using this instruction in user mode.

    — EDIT —

    My answer above is outdated for the 55xx series of CPUs which use QPI links. These links interconnect CPU sockets directly without an intervening chipset, as in:
    http://ark.intel.com/products/37111/Intel-Xeon-Processor-X5570-%288M-Cache-2_93-GHz-6_40-GTs-Intel-QPI%29

    However, since the L3 cache in each CPU is inclusive, snoops over the QPI links only occur when the local L3 cache indicates the line is nowhere in the local socket. Likewise, the remote socket’s L3 can quickly respond to a cross-snoop without bothering the cores, assuming the line isn’t there either.

    So, the inclusive L3 caches should minimize inter-socket coherency overhead, it’s just not due to a chipset snoop filter in your case.

    • 0