How the OS behaves in deciding when to use an extra CPU?

I typically got this question from a customer who was explicitly trying to know: How the OS behaves in deciding when to use an extra CPU to process COM+ requests?

Ideally to answer this in one line I would have to say: there is no additional way for the OS to decide that a thread is a COM+ thread or a thread is from any other process for example say notepad.exe.

Please note: all threads from user mode processes are executing at PASSIVE_LEVEL. User-mode code executes at PASSIVE_LEVEL. This is the level at which threads run. In fact https://blogs.msdn.microsoft.com/doronh/2010/02/02/what-is-irql/ says: if you look at the specific definition of “thread” in NT, it pretty much only covers code that runs in the context of a specific process, at PASSIVE_LEVEL or APC_LEVEL.

There is no separate distinction which the OS will make for a COM+ thread.

If you read through "Operating System Concepts" & "Operating System Concept Essentials" by Silberschatz and Galvin, it says:

Almost all processes alternate between two states in a continuing cycle:

• A CPU burst of performing calculations, and

• An I/O burst, waiting for data transfer in or out of the system.

CPU bursts vary from process to process, and from program to program, but an extensive study shows frequency patterns similar to the one shown in the diagram below:

<diagram snipped from the same OS book referred earlier>

From the task manager you can set the processor affinity of a process (see below) but the default is set for all. So by choosing any specific processor (choosing a subset) doesn’t make computations fast.

You can even change the priority of a process from the task manager but it can make the system highly unstable. Ideally as said before:  There is no separate distinction which the OS will make for a COM+ thread. User-mode code executes at PASSIVE_LEVEL.

IMHO: the task manager (shown in the screen shot above) sets the priority class of process as discussed in https://msdn.microsoft.com/en-us/library/windows/desktop/ms685100(v=vs.85).aspx. Use HIGH_PRIORITY_CLASS with care. If a thread runs at the highest priority level for extended periods, other threads in the system will not get processor time. If several threads are set at high priority at the same time, the threads lose their effectiveness.

As the MSDN link says: You should almost never use REALTIME_PRIORITY_CLASS, because this interrupts system threads that manage mouse input, keyboard input, and background disk flushing. This class can be appropriate for applications that "talk" directly to hardware or that perform brief tasks that should have limited interruptions.