What is the performance cost of a Win32 process switch?

Question

I know the cost of a physical Win32 thread context switch is estimated at between 2-8k cycles. Any estimates on the cost of a process switch?

Answer 1

Instead of asking for estimates, I'd test it. Start with a program like:

#include <windows.h>

int main() { 
    for (int i=0; i<1000000; i++)
        Sleep(0);
    return 0;
}

Then create a parent program that spawns (say) 32 copies of this, and then uses WaitForMultipleObjects to wait for them to all finish. Measure the (wall) time from start to finish, and divide by the total number of process switches. Of course, you want to run on a relatively quiescent system to get a meaningful result.

Answer 2

A quote from "Windows Internals 5Ed":

Windows must determine which thread should run next. When Windows selects a new thread to run, it performs a context switch to it. A context switch is the procedure of saving the volatile machine state associated with a running thread, loading another thread’s volatile state, and starting the new thread’s execution.

Windows schedules at the thread granularity. This approach makes sense when you consider that processes don’t run but only provide resources and a context in which their threads run. Because scheduling decisions are made strictly on a thread basis, no consideration is given to what process the thread belongs to. For example, if process A has 10 runnable threads, process B has 2 runnable threads, and all 12 threads are at the same priority, each thread would theoretically receive one-twelfth of the CPU time—Windows wouldn’t give 50 percent of the CPU to process A and 50 percent to process B.

...

A thread’s context and the procedure for context switching vary depending on the processor’s architecture. A typical context switch requires saving and reloading the following data: A. Instruction pointer B. Kernel stack pointer C. A pointer to the address space in which the thread runs (the process’s page table directory). The kernel saves this information from the old thread by pushing it onto the current (old thread’s) kernel-mode stack, updating the stack pointer, and saving the stack pointer in the old thread’s KTHREAD block. The kernel stack pointer is then set to the new thread’s kernel stack, and the new thread’s context is loaded. If the new thread is in a different process, it loads the address of its page table directory into a special processor register so that its address space is available. Control passes to the new thread’s restored instruction pointer and the new thread resumes execution.

So the only overhead for thread-context switch to another process is as minimal as setting the value of one processor register - totally negligible.