CODEWITHSUNDEEP
pythonwindowscpu
Sir2B
Sir2B

Reputation: 1079

equally busy cpu cores

I recognized lately when running a computationally intensive python program (without threading), that under Windows (Win8.1 x64) not one CPU Core (of my 4 logical, 2 physical Cores) is fully occupied, instead every logical Core is busy by ~25%. All in all this correspond with one core 100% busy. Does Windows spread the tasks, but not really good? Has this something to do, to keep the Cores as cold as possible? Or has it something to do with Python? I run the same program under linux and here happend what I expected (one Core 100% busy)

Upvotes: 1

Views: 373

Answers (1)

tal shachar
tal shachar

Reputation: 118

What you observe in Windows is actually what one would expect from a default behavior of an interactive CPU scheduler (be that Windows or Linux, other Unix variants or macOS).

When you execute a thread, the OS keeps on sending timed interrupts (clock interrupts) which brings the control over the CPU core from user space (the app you're running) back to kernel space (the OS running the process) and this enables the OS to reschedule the process to run on the same (or other) CPU core after other processes had their share of the "CPU pie". This in principle also happens if only your process is the main CPU consumer (there are usually always other processes in addition to yours that run in the background)

This behavior is a highly important feature of an interactive scheduling mode (which is the default for most OS nowadays, since they are, well, interactive...) Because it allows all running processes to get a slice of the CPU resource without starving any of them. This allows for every process running to "feel" interactive by sharing the entire CPU resources between them and not letting "CPU hogs" to take the CPU and not give it back.

Now, with that being said, you can tweak that behavior. For example, like what you did by setting affinity of a process to a single core or setting "real time" priority to a process.

Either of them will cause the process to keep running on the same core (affinity is trivial, you ask the OS to run it only on 1 core). Realtime just stops interrupting the process. It makes your machine less interactive but also stops interrupting the running process so it keeps on going on the same core it started running on.

Now, regarding the behavior you specified on Linux. I think it's one of the following two explenations:

  1. You are somehow scheduling the process to run on SCHED_FIFO without realizing it (this is the Windows equivalent of "real time")

    In order to verify it, use the PID of your process and execute

    chrt -p <your process PID>

  2. You are misinterpreting some tool that showed you as if the process is running on a single core while in fact it is spread across all cores.

If you could elaborate how you reached conclusion that in Linux it runs on all cores I'll be more than glad to hear.

Upvotes: 3

Related Questions