|
|
|
|
|
by willvarfar
5351 days ago
|
|
Thank you for making me challenge my assumptions and memory. I've asked around a bit and am fairly sure of my facts again, and my understanding is: * kernel mode is cheaper than ever to reach; SYSCALL/SYSENTER etc so its not even an interrupt and there are no hardware threads or anything involved * in kernel mode, the thread can get straight at the buffer and the locks that protect it; there is nothing that we'd call a 'context switch' in there * being as this seems to be what is meant by monolithic kernel, surely its the same on freebsd too? |
|
When you make a system call, a trap is issued that causes the hardware switch to kernel mode.
The hardware pushes onto the per-process kernel stack the pc, status word, and the kernel code takes care of saving the registers, esp, etc.. this is called a task context switch. Context switching between processes is much more expensive but task context switching is still considered a context switch.
When you are making a system call, it's still much more expensive then most of the work you are doing in your program hellepoll and hence it's your bottleneck. This is why you don't see your process's CPU at 100%.
On a related note, whenever you have a program doing a lot of network IO, you are essentially causing a lot of process context switches because each time you get data on the wire you cause a context switch because the kernel needs to handle this hardware interrupt.