Hmm, no hard figures? Sounds like an anecdote... did you see the situation persist for, say, more than a minute?

If so you probably ran into an extreme edge case. I can think of a few things that might contribute to something like that e.g.

- running on a server, where System Properties...Advanced...Performance...Advanced...Processor Scheduling was set to "Background services" rather than "Programs" (or vice-versa)

- other processes having their processor affinities set either permanently or while running (via Task Manager) such that the Windows scheduler's best remaining option is to run user apps on one core

- something or someone messing around with process priorities

On modern SMP systems OS schedulers are extremely serious pieces of software, it's hard to overstate how much effort goes into them to make them reliable and performant under a huge variety of loads. Manually messing around with processor affinities or process priorities is almost always a mistake i.e. will on average reduce performance. The proposed 4-instance use case is not unusual, if there were persistent Windows scheduler problems doing something like that there would be all kinds of blog posts and complaints about it, and they just aren't out there.

Even if someone has systems-level knowledge and experience, and they believe they've identified a case where manual intervention will help, that doesn't address the elephant in the room - the fact that more and more servers and even desktops are running virtualized. So the OS scheduler is only working with virtual CPUs; the hypervisor has final say.

Come to think of it, virtualization is one case where you can see unbalanced CPU utilizations. For example, suppose you have:

- a 12-core Xeon Hyper-V host
- 3 defined virtual machines, each assigned 4 virtual CPUs, each running a Windows OS such as Server 2012 R2

Two of the VMs are not particularly busy, but on the third you run 4 instances of an app. If you look at Task Manager on that VM, chances are you'll see a pretty even distribution of CPU load across all 4 virtual CPUs. However, if you look at Task Manager on the host, you'll probably see only 4 of the 12 "real" cores being busy. This is because hypervisors try to avoid switching cores if they don't have to, because doing complete-VM context switches is expensive.

There are other potential flies in the scheduling ointment:

- Hyper-Threading: HT CPUs present 2x the logical processors i.e. 4 cores w/HT presents 8 logical processors to the OS. Dumb schedulers would treat them all the same, even though on a single core HT buys you only 10% - 25% extra performance. Smart schedulers know about HT so if logical CPU0 is running an intense process, it will run the next intense process on CPU2 instead of CPU1 (which is still the first physical core), then the next on CPU4 etc. You can sometimes see Windows doing this if you watch Task Manager while starting and running multiple apps.

- Intel Turbo Boost (and AMD equivalent): can boost speeds of individual core(s) under certain conditions. This mainly improves single-process performance on a single core. I believe modern Windows OS schedulers know about Turbo Boost. However, in the OP's case I don't think it'll come into play. He has jobs that run multiple tens of minutes, thermal loads are likely to limit how much Turbo Boost comes into play. He's probably better off trying to get 4 app instances running on 4 separate physical cores. All things considered, it's probably best just to let Windows schedule those itself

>Not really.
>
>>When you saw that happen, were the other cores busy?