[xv6-kernel] Scheduling

Context Switching

• a user-kernel transition(system call or interrupt)

• a context switch to the local CPU's scheduler thread

• a context switch to a new process's kernel thread

• a trap return to the user-level process

• Xv6 use two context switches

  • Because the scheduler runs on its own stack in order to simplify cleaning up user process

The mechanics of switching between a kernel thread and a scheduler thread

• Every xv6 process has its own kernel stack and register set
• Each CPU has a seperate scheduler thread
  • For use when it is executing the scheduler rather than any process's kernel thread
• Switching from one thread to another thread
  • saving the old thread's CPU registers
  • restoring the previously-saved registers of the new thread
  • %esp and %eip are saved and restored
    • CPU will switch stacks and switch what code it is executing

Swtch

• saves and restore contexts (register sets)
• When a process give up the CPU
  • the process kernel thread call swtch
  • save kernel thread's context and return to the scheduler context
  • struct context*: a pointer to a structure stored on the kernel stack
• void swtch ( struct context** old, struct context * new)
  • pushes the current CPU register onto the stack
  • saves the stack pointer in *old
  • swtch copies new to %esp
  • pops previously saved register

Sched

• Example : yield in trap
  • call sched
    • call swtch
      1) to save the current context in proc->context
      2) switch to the scheduler context previously saved in cpu->scheduler
    • The flow of swtch
      1) copying old's arguments from the stack to the caller-saved registers %eax and %edx
      (swtch must to this before it changes the stack pointer (2969-2970) and can no longer access the arguments via %esp)
      2) pushing the register state
      3) creating a context structure on the current stack
      4) calle saved registers : %ebp, %ebx, %esi, %edi, and %esp registers
      5) pushing the %ebp, %ebx, %esi, %edi
      - it saves the last implicitly as the context* written to *old
      6) %eip : the program counter ; it has already been saved on the stack by the call instruction that invoked swtch
      7) moving the pointer to the new context into the stack pointer
      8) swtch can invert the sequence to restore new context
      9) popping the values for %edi, %esi, %ebx, %ebp
      10) the instruction addresss is from new context because the stack pointer is changed
    • In this example, the context had been saved by scheduler's call to /swtch/.
    • It returns not to sched but to scheduler
    • stack pointer points at the current CPU's scheduler stack, not initproc's kernel stack

Scheduling

• A process that wants to give up the CPU
  • must acquire the process table lock ptable (for sync of ptable)
  • release any other locks it is holding
  • update its own state (proc->state)
  • call sched
  • double checks those conditions