4 ms·

> you're running instructions on the actual CPU Just how many times is the average operating system workload (with or without a virtual machine also running a

> you're running instructions on the actual CPU Just how many times is the average operating system workload (with or without a virtual machine also running a second average operating system workload) context switching a second? Like... unless I'm wrong... the kernel is the main process, and then it slices up processes/threads, and each time those run, they have their own EAX/EBX/ECX/ESP/EBP/EIP/etc. (I know it's RAX, etc. for 64-bit now) How many cycles is a thread/process given before it context switches to the next one? How is it managing all of the pushfd/popfd, etc. between them? Is this not how modern operating systems work, am I misunderstanding?

saagarjha 3y ago
Usually a few hundred to a few thousand times a second.
- bravetraveler 3y ago
  I've seen in the neighborhood of dozens of thousands of times on the high end For anyone interested in seeing this on the nearest Linux box: vmstat -S M 1 Watch the 'cs' column go wild
toast0 3y ago
> How many cycles is a thread/process given before it context switches to the next one? Depends on a lot of things. If it's a compute heavy task, and there's no I/O interrupts, the task gets one "timeslice", timeslices vary, but typical times are somewhere in the neighborhood of 1 ms to 100 ms. If it's an I/O heavy task, chances are the task returns from a syscall with new data to read (or because a write finished), does a little bit of work, then does another syscall with I/O. Lots of context switches in network heavy code (io_uring seems promising). > How is it managing all of the pushfd/popfd, etc. between them? The basic plan is when the kernel takes an interrupt (or gets a syscall, which is an interrupt on some systems and other mechanisms on others), the kernel (or the cpu) loads the kernel stack pointer for the current thread, then it pushes all the (relevant) cpu registers onto the stack, then the kernel business it taken care of, the scheduler decides which userspace thread to return to (which might be the same one that was interrupted or not), the destination thread's kernel stack is switched to, registers are popped, then the thread's userspace stack is switched to, then userspace execution resumes.
MisterTea 3y ago
> Like... unless I'm wrong... the kernel is the main process, A nice way of thinking about it is the kernel visualizes the CPU among multiple programs. Great reading material on all this OS stuff: https://pages.cs.wisc.edu/~remzi/OSTEP/ https://pages.cs.wisc.edu/~remzi/OSTEP/

saagarjha 3y ago

Usually a few hundred to a few thousand times a second.

bravetraveler 3y ago
I've seen in the neighborhood of dozens of thousands of times on the high end For anyone interested in seeing this on the nearest Linux box: vmstat -S M 1 Watch the 'cs' column go wild

toast0 3y ago

> How many cycles is a thread/process given before it context switches to the next one? Depends on a lot of things. If it's a compute heavy task, and there's no I/O interrupts, the task gets one "timeslice", timeslices vary, but typical times are somewhere in the neighborhood of 1 ms to 100 ms. If it's an I/O heavy task, chances are the task returns from a syscall with new data to read (or because a write finished), does a little bit of work, then does another syscall with I/O. Lots of context switches in network heavy code (io_uring seems promising). > How is it managing all of the pushfd/popfd, etc. between them? The basic plan is when the kernel takes an interrupt (or gets a syscall, which is an interrupt on some systems and other mechanisms on others), the kernel (or the cpu) loads the kernel stack pointer for the current thread, then it pushes all the (relevant) cpu registers onto the stack, then the kernel business it taken care of, the scheduler decides which userspace thread to return to (which might be the same one that was interrupted or not), the destination thread's kernel stack is switched to, registers are popped, then the thread's userspace stack is switched to, then userspace execution resumes.

MisterTea 3y ago

> Like... unless I'm wrong... the kernel is the main process, A nice way of thinking about it is the kernel visualizes the CPU among multiple programs. Great reading material on all this OS stuff: https://pages.cs.wisc.edu/~remzi/OSTEP/ https://pages.cs.wisc.edu/~remzi/OSTEP/