A friend of mine says that a process always jumps between cores even if you pin a process to a specific core within operating system. He says that the processor manufacturers do this so that the processors won't burn due to hotspots (burning of cores actually happening or not is besides the point).

He also says, for example windows task manager is not correct as it can't follow what processor does internally. Therefore untrustworthy... He swears that he saw some Intel documentation which explains it. (well he could not find it)

I tried to tell him that this is illogical as doing so would invalidate caches and pipelines etc. but as there is also no documentation saying otherwise it is kind of difficult to prove.

Does anybody know documentation or can make a bulletproof explanation which proves either theory?


  • The hardware your friend describes does not exist.
    – Ramhound
    Aug 21, 2019 at 4:27
  • If he saw it in some Intel documentation then he needs to provide evidence. I've definitely seen temperatures rise much faster on particular cores where demanding tasks have been set to run those cores within the OS. Other core temperatures do rise, but not as much and the effect is explained by having a connected heat spreader. Your friend probably misunderstood a datasheet comment stating that allowing tasks to migrate cores could allow for better thermal efficiency rather than "this is done without intervention".
    – Mokubai
    Aug 21, 2019 at 6:44
  • The CPU has no concept of processes or threads. All it does is execute code. What core a specific piece of code will run on at any given time is up to the kernel thread scheduler. As it should be. It would be highly inappropriate for the CPU to meddle with this. And totally unnecessary. I think your friend misunderstood what he read.
    – LMiller7
    Aug 21, 2019 at 6:45

1 Answer 1


I don't think there is deliberate "randomization" done in the processor to avoid heat spots or whatever.

Ring 0 code can read CPU registers to identify which core the code is running on, and can then give up it's CPU time if it's on the wrong core. At the very minimum, one core always has the BSP bootstrap flag set during reset at BIOS initialization (we're talking about an x86 CPU). You can read that register to ensure you only run on that core. But there's almost certainly some other ID mechanism that can be used.

Since the OS privileged kernel code handles process switching, you could definitely give the OS a feature to lock processes onto a specific core, even if that just means giving up CPU time until the switch lands on that core. You could also set all other processes to avoid that core to keep it open for the process you want.

So whether task manager does it or not, you can in theory definitely know which core which process is running on, and lock them to those cores.

Now, does Intel have hidden hardware that's actually switching the ID's of cores around so you don't know which physical core you're actually running on? Doubt it. The CPU reports per-core temperatures, and you can see the temperature rising on different cores using a single threaded process that you lock to different cores.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .