How expensive are kernel context switches compared to user space context switches?

Question

According to C10k and this document , server throughput with 1 thread per connection degrades as more and more clients connect and more and more threads are created. According to these two sources, this is due to the fact that the more threads exist, the more time is spent switching contexts compared to the actual work performed by these threads. Paged servers are likely to suffer from degradation in performance with high numbers of connections.

However, the servers to which events will enter also perform context switches between clients, they simply do this in user space.

• Why do these userpace contexts switch faster than kernel thread context switches?
• What exactly makes the kernel context switch much more expensive?
• How expensive is the kernel context switch? How long does it take?
• Does kernel switching time depend on the number of threads?

What interests me most is how the Linux kernel handles context switching, but information about other operating systems is also welcome.

Answer 1

• Why do these userpace contexts switch faster than kernel thread context switches?

Because the CPU does not need to switch to kernel mode and return to user mode.

• What exactly makes the kernel context switch much more expensive?

Basically, switching to kernel mode. IIRC, page tables are the same in kernel mode and user mode in Linux, so at least there is no penalty for canceling TLBs.

• How expensive is the kernel context switch? How long does it take?

It is required to measure and can vary from machine to machine. I assume that a typical desktop / server machine these days can execute several hundred thousand context switches per second, possibly several millions.

• Does kernel switching time depend on the number of threads?

Depends on how the kernel handler handles this. AFAIK, on ​​Linux it is quite efficient even with a large number of threads, but more threads mean that using more memory means more cache pressure and therefore lower performance. I also expect some overhead to process thousands of sockets.