Hi Professor, Your xv6 video lectures have been brilliant and helped me understand the operating system at a much deeper level. Would it be possible for you to also release the drawings/notes that you used in the videos? Any format like PDF or PPT would be greatly appreciated. Having access to those supplementary materials would further enhance my learning experience.
I am not sure why you mention that there is an additional context switch involved to the "scheduler thread". As I understand, when thread1 traps into the kernel's timer handler, process1's registers are saved off into a user stack frame (either by hardware or by the software handler, depending on the machine). The timer handler then invokes the scheduler code (still in the context of process1). The scheduler code picks another process to execute (say, process2), then copies the contents from the user stack frame into the process control block for process1. Then it copies contents from process2's process control block into the user stack frame (basically replaces process1's user stack frame). Now, when the kernel gets back to usermode, the values from the user stack frame are copied into the registers (either by the hardware or by a handler, depending on the machine), and the kernel "returns" to process2. So, in essence, we went from process1 (usermode) -> process1 (kernel mode) -> process 2 (kernel mode) -> process 2(user mode).
You might be right in some other os. But in xv6, it has a scheduler context associated with each cpu i think (stored in cpu struct). "Scheduler thread" has its own states of registers, stack pointer (actually a kernel stack pointer), program counter to be restored to do the scheduling job whenever the cpu is asked to do a context switching. I think using the term "context switch" for "scheduler thread" is precise here. For more details, you may look at the manual of xv6 written by the developing team at MIT starting off from page 68. I drop the link here pdos.csail.mit.edu/6.S081/2020/xv6/book-riscv-rev1.pdf. The scheduler mechanism in xv6 is not designed as a function call but as a thread which keeps examining the state of each process and decides what to run next. Therefore, you need to switch the "scheduler thread" back with its states every time you want it to work. Does this solve what you have been confused about?
Hi Professor,
Your xv6 video lectures have been brilliant and helped me understand the operating system at a much deeper level. Would it be possible for you to also release the drawings/notes that you used in the videos? Any format like PDF or PPT would be greatly appreciated. Having access to those supplementary materials would further enhance my learning experience.
Incredible video series. Thank you professor
Very good lessons, thanks.
Thank u. It helps me a lot.
Glad to hear that
Thank you sir !!
I am not sure why you mention that there is an additional context switch involved to the "scheduler thread". As I understand, when thread1 traps into the kernel's timer handler, process1's registers are saved off into a user stack frame (either by hardware or by the software handler, depending on the machine). The timer handler then invokes the scheduler code (still in the context of process1). The scheduler code picks another process to execute (say, process2), then copies the contents from the user stack frame into the process control block for process1. Then it copies contents from process2's process control block into the user stack frame (basically replaces process1's user stack frame). Now, when the kernel gets back to usermode, the values from the user stack frame are copied into the registers (either by the hardware or by a handler, depending on the machine), and the kernel "returns" to process2. So, in essence, we went from process1 (usermode) -> process1 (kernel mode) -> process 2 (kernel mode) -> process 2(user mode).
You might be right in some other os. But in xv6, it has a scheduler context associated with each cpu i think (stored in cpu struct). "Scheduler thread" has its own states of registers, stack pointer (actually a kernel stack pointer), program counter to be restored to do the scheduling job whenever the cpu is asked to do a context switching. I think using the term "context switch" for "scheduler thread" is precise here. For more details, you may look at the manual of xv6 written by the developing team at MIT starting off from page 68. I drop the link here pdos.csail.mit.edu/6.S081/2020/xv6/book-riscv-rev1.pdf. The scheduler mechanism in xv6 is not designed as a function call but as a thread which keeps examining the state of each process and decides what to run next. Therefore, you need to switch the "scheduler thread" back with its states every time you want it to work. Does this solve what you have been confused about?