ICS143A: Principles of Operating Systems Lecture 13: Context switching

Slides:



Advertisements
Similar presentations
A very simple kernel Anders P. Ravn April A kernel specification /* kernel.h Interface to a lightweight kernel that implements concurrent processes.
Advertisements

CS 4284 Systems Capstone Godmar Back Processes and Threads.
University of Washington Last Time For loops  for loop → while loop → do-while loop → goto version  for loop → while loop → goto “jump to middle” version.
Context Switch Animation Another one by Anastasia.
Machine-Level Programming III: Procedures Apr. 17, 2006 Topics IA32 stack discipline Register saving conventions Creating pointers to local variables CS213.
X86 segmentation, page tables, and interrupts 3/17/08 Frans Kaashoek MIT
Project 2 Roadmap. Background – Context Switching One processor and multiple threads running concurrently – How?!! Give each thread a small time quantum.
Context switch in Linux
PC hardware and x86 3/3/08 Frans Kaashoek MIT
1 Function Calls Professor Jennifer Rexford COS 217 Reading: Chapter 4 of “Programming From the Ground Up” (available online from the course Web site)
– 1 – , F’02 ICS05 Instructor: Peter A. Dinda TA: Bin Lin Recitation 4.
1 Homework Reading –PAL, pp , Machine Projects –Finish mp2warmup Questions? –Start mp2 as soon as possible Labs –Continue labs with your.
Machine-Level Programming III: Procedures Jan 30, 2003
Stack Activation Records Topics IA32 stack discipline Register saving conventions Creating pointers to local variables February 6, 2003 CSCE 212H Computer.
ESP int f(int x) {.... } int g(int y) { …. f(2); …. } int main() { …. g(1); …. } EIP 100: 200: 250: 300: 350:
6.828: PC hardware and x86 Frans Kaashoek
Multitasking Mr. Mahendra B. Salunke Asst. Prof. Dept. of Computer Engg., STES SITS, Narhe, Pune-41 STES Sinhgad Institute of Tech. & Science Dept. of.
1 Carnegie Mellon Stacks : Introduction to Computer Systems Recitation 5: September 24, 2012 Joon-Sup Han Section F.
University of Washington Today More on procedures, stack etc. Lab 2 due today!  We hope it was fun! What is a stack?  And how about a stack frame? 1.
Fabián E. Bustamante, Spring 2007 Machine-Level Programming III - Procedures Today IA32 stack discipline Register saving conventions Creating pointers.
Derived from "x86 Assembly Registers and the Stack" by Rodney BeedeRodney Beede x86 Assembly Registers and the Stack Nov 2009.
15-410, S’ Hardware Overview Jan. 19, 2004 Dave Eckhardt Bruce Maggs L04_Hardware “Dude, what were you thinking?”
LINUX System : Lecture 7 Process Bong-Soo Sohn Lecture notes acknowledgement : The design of UNIX Operating System.
Chapter 4 Process Abstraction Chien-Chung Shen CIS, UD
Low Level Programming Lecturer: Duncan Smeed The Interface Between High-Level and Low-Level Languages.
Machine-level Programming III: Procedures Topics –IA32 stack discipline –Register saving conventions –Creating pointers to local variables.
Functions/Methods in Assembly
6. HAL and IDT ENGI 3655 Lab Sessions. Richard Khoury2 Textbook Readings  Interrupts ◦ Section  Hardware Abstraction Layer ◦ Section
10. Epilogue ENGI 3655 Lab Sessions.  We took control of the computer as early as possible, right after the end of the BIOS  Our multi-stage bootloader.
What You Need to Know for Project Three Steve Muckle Wednesday, February 19 th Spring 2003.
1 Assembly Language: Function Calls Jennifer Rexford.
Discussions on hw3 Objective –To implement multitasking of 3 Tiny-UNIX processes on the SAPC –Each process tries to output data to the COM2 output port.
What You Need to Know for Project Three Dave Eckhardt Steve Muckle.
Virtualizing the CPU: Processes 1. How to provide the illusion of many CPUs? CPU virtualizing – The OS can promote the illusion that many virtual CPUs.
Assembly function call convention
Reading Condition Codes (Cont.)
Homework / Exam Return and Review Exam #1 Reading Machine Projects
C function call conventions and the stack
Operating Systems Engineering
Processes.
CS 5204 Operating Systems Processes and Threads Godmar Back.
143A: Principles of Operating Systems Lecture 7: System boot
Anton Burtsev February, 2017
ICS143A: Principles of Operating Systems Final recap, sample questions
Anton Burtsev February, 2017
Homework Reading Machine Projects Labs PAL, pp ,
Anton Burtsev February, 2017
Aaron Miller David Cohen Spring 2011
Homework In-line Assembly Code Machine Language
Anton Burtsev February, 2017
x86 segmentation, page tables, and interrupts
Anton Burtsev November, 2017
Recitation 2 – 2/4/01 Outline Machine Model
Machine-Level Programming 4 Procedures
Discussions on hw3 Objective
Practical Session 2, Processes and Scheduling
Practical Session 1 System Calls
More examples How many processes does this piece of code create?
Assembly Language Programming II: C Compiler Calling Sequences
Machine-Level Programming III: Procedures Sept 18, 2001
Discussions on HW2 Objectives
Discussions on HW2 Objectives
Low-Level Thread Dispatching on the x86
System Calls System calls are the user API to the OS
Practical Session 2, Processes and Scheduling
“Way easier than when we were students”
* Preemptive Scheduling Fall 2002
Practical Session 1 System Calls
Presentation transcript:

ICS143A: Principles of Operating Systems Lecture 13: Context switching Anton Burtsev February, 2017

User mode Two stacks Kernel and user Kernel stack is empty

Page table GDT

Page table GDT

Timer interrupt

Interrupt path

Where does IDT (entry 32) point to? vector32: pushl $0 // error code pushl $32 // vector # jmp alltraps Automatically generated From vectors.pl vector.S

Kernel stack after interrupt

alltraps() 3254 alltraps: 3255 # Build trap frame. 3256 pushl %ds 3257 pushl %es 3258 pushl %fs 3259 pushl %gs 3260 pushal 3261 3262 # Set up data and per−cpu segments. 3263 movw $(SEG_KDATA<<3), %ax 3264 movw %ax, %ds 3265 movw %ax, %es 3266 movw $(SEG_KCPU<<3), %ax 3267 movw %ax, %fs 3268 movw %ax, %gs 3269 3270 # Call trap(tf), where tf=%esp 3271 pushl %esp 3272 call trap

Kernel stack after interrupt

alltraps() 3254 alltraps: 3255 # Build trap frame. 3256 pushl %ds 3257 pushl %es 3258 pushl %fs 3259 pushl %gs 3260 pushal 3261 3262 # Set up data and per−cpu segments. 3263 movw $(SEG_KDATA<<3), %ax 3264 movw %ax, %ds 3265 movw %ax, %es 3266 movw $(SEG_KCPU<<3), %ax 3267 movw %ax, %fs 3268 movw %ax, %gs 3269 3270 # Call trap(tf), where tf=%esp 3271 pushl %esp 3272 call trap

trap() 3351 trap(struct trapframe *tf) 3352 { ... 3363 switch(tf−>trapno){ 3364 case T_IRQ0 + IRQ_TIMER: 3365 if(cpu−>id == 0){ 3366 acquire(&tickslock); 3367 ticks++; 3368 wakeup(&ticks); 3369 release(&tickslock); 3370 } 3372 break; 3423 if(proc && proc−>state == RUNNING && tf−>trapno == T_IRQ0+IRQ_TIMER) 3424 yield();

Invoke the scheduler 2777 yield(void) 2778 { 2779 acquire(&ptable.lock); 2780 proc−>state = RUNNABLE; 2781 sched(); 2782 release(&ptable.lock); 2783 }

Start the context switch 2758 sched(void) 2759 { ... 2771 swtch(&proc−>context, cpu−>scheduler); 2773 }

swtch() 2958 swtch: 2959 movl 4(%esp), %eax 2960 movl 8(%esp), %edx 2961 2962 # Save old callee−save registers 2963 pushl %ebp 2964 pushl %ebx 2965 pushl %esi 2966 pushl %edi 2967 2968 # Switch stacksh 2969 movl %esp, (%eax) 2970 movl %edx, %esp 2971 2972 # Load new callee−save registers 2973 popl %edi 2974 popl %esi 2975 popl %ebx 2976 popl %ebp 2977 ret swtch() void swtch(struct context **old, struct context *new); First argument: A pointer to a pointer to a context That we're going to save Second argument: A pointer to a context We're going to restore

Context data structure 2093 struct context { 2094 uint edi; 2095 uint esi; 2096 uint ebx; 2097 uint ebp; 2098 uint eip; 2099 };

swtch() 2958 swtch: 2959 movl 4(%esp), %eax 2960 movl 8(%esp), %edx 2961 2962 # Save old callee−save registers 2963 pushl %ebp 2964 pushl %ebx 2965 pushl %esi 2966 pushl %edi 2967 2968 # Switch stacksh 2969 movl %esp, (%eax) 2970 movl %edx, %esp 2971 2972 # Load new callee−save registers 2973 popl %edi 2974 popl %esi 2975 popl %ebx 2976 popl %ebp 2977 ret swtch() 2093 struct context { 2094 uint edi; 2095 uint esi; 2096 uint ebx; 2097 uint ebp; 2098 uint eip; 2099 };

Stack inside swtch() and its two arguments (passed on the stack)

Context is always top of some stack

Context is always top of some stack, why? Remember how we initialized each CPU last time?

1251 static void 1252 mpenter(void) 1253 { 1254 switchkvm(); 1255 seginit(); 1256 lapicinit(); 1257 mpmain(); 1258 }

1260 // Common CPU setup code. 1261 static void 1262 mpmain(void) 1263 { 1264 cprintf("cpu%d: starting\n", cpu−>id); 1265 idtinit(); // load idt register 1266 xchg(&cpu−>started, 1); 1267 scheduler(); // start running processes 1268 }

We ended boot by starting a scheduler

Remember the stack of the boot process?

How does scheduler start? 2458 scheduler(void) 2459 { 2462 for(;;){ 2468 for(p = ptable.proc; p < &ptable.proc[NPROC]; p++){ 2469 if(p−>state != RUNNABLE) 2470 continue; 2475 proc = p; 2476 switchuvm(p); 2477 p−>state = RUNNING; 2478 swtch(&cpu−>scheduler, proc−>context); 2479 switchkvm(); 2483 proc = 0; 2484 } 2487 } 2488 } Chooses next process to run Switches to it From the current context

2478 swtch(&cpu−>scheduler, proc−>context); So when the scheduler context switched the first time 2478 swtch(&cpu−>scheduler, proc−>context); It saved its own context &cpu−>scheduler And restored a context of the first process proc−>context

This is how stack looked like when scheduler() invoked swtch() for the first time What is this context?

This is how stack looked like when scheduler() invoked swtch() for the first time What is this context? It's the context of the first process scheduler decides to run

Save context of the scheduler

swtch() 2958 swtch: 2959 movl 4(%esp), %eax // struct context **old 2960 movl 8(%esp), %edx // struct context *new 2961 2962 # Save old callee−save registers 2963 pushl %ebp 2964 pushl %ebx 2965 pushl %esi 2966 pushl %edi 2967 2968 # Switch stacksh 2969 movl %esp, (%eax) // load current context (top of current stack) into // the memory location pointed by *old 2970 movl %edx, %esp // set stack to be equal to *new (the top of the new context) 2971 2972 # Load new callee−save registers 2973 popl %edi 2974 popl %esi 2975 popl %ebx 2976 popl %ebp 2977 ret swtch()

This is why the context is the top of some stack Initially it was the stack of mpenter() On which scheduler started Then first process... Then scheduler again And the next process...

Back to main context switch: so context is always top of some stack

Currently the *new context is the stack of the scheduler We switch to the scheduler, It runs on the stack of the boot process

swtch() 2958 swtch: 2959 movl 4(%esp), %eax // struct context **old 2960 movl 8(%esp), %edx // struct context *new 2961 2962 # Save old callee−save registers 2963 pushl %ebp 2964 pushl %ebx 2965 pushl %esi 2966 pushl %edi 2967 2968 # Switch stacks 2969 movl %esp, (%eax) // load current context (top of current stack) into // the memory location pointed by *old 2970 movl %edx, %esp // set stack to be equal to *new (the top of the new context) 2971 2972 # Load new callee−save registers 2973 popl %edi 2974 popl %esi 2975 popl %ebx 2976 popl %ebp 2977 ret swtch()

And now: exit from swtch() 2959 movl 4(%esp), %eax 2960 movl 8(%esp), %edx 2961 2962 # Save old callee−save registers 2963 pushl %ebp 2964 pushl %ebx 2965 pushl %esi 2966 pushl %edi 2967 2968 # Switch stacks 2969 movl %esp, (%eax) 2970 movl %edx, %esp 2971 2972 # Load new callee−save registers 2973 popl %edi 2974 popl %esi 2975 popl %ebx 2976 popl %ebp 2977 ret And now: exit from swtch()

Where does this swtch() return?

Where does this swtch() return? Scheduler After all remember We started with timer interrupt Entered the kernel Entered schedule() Entered switch And are currently on our way from the process into the scheduler

2468 for(p = ptable.proc; p < &ptable.proc[NPROC]; p++){ What does scheduler do? 2458 scheduler(void) 2459 { 2462 for(;;){ 2468 for(p = ptable.proc; p < &ptable.proc[NPROC]; p++){ 2469 if(p−>state != RUNNABLE) 2470 continue; 2475 proc = p; 2476 switchuvm(p); 2477 p−>state = RUNNING; 2478 swtch(&cpu−>scheduler, proc−>context); 2479 switchkvm(); 2483 proc = 0; 2484 } 2487 } 2488 } Chooses next process to run Switches to it

What does stack look like when scheduler() invokes swtch()? What is this context?

What does stack look like when scheduler() invokes swtch()? What is this context? Right the context of the next process to run

We save the context of the scheduler again Restore the context of the next proces

2478 swtch(&cpu−>scheduler, proc−>context); Remember, from inside the scheduler we invoked swtch() as 2478 swtch(&cpu−>scheduler, proc−>context); Hence, we save context of the scheduler into &cpu−>scheduler And restore proc−>context

Stacks and context inside swtch()

Exiting back to user-level Stack inside sched() Normal returns until back to alltrap()

alltraps(): Exiting back into user level process ... 3020 # Call trap(tf), where tf=%esp 3021 pushl %esp 3022 call trap 3023 addl $4, %esp 3024 3025 # Return falls through to trapret... 3026 .globl trapret 3027 trapret: 3028 popal 3029 popl %gs 3030 popl %fs 3031 popl %es 3032 popl %ds 3033 addl $0x8, %esp # trapno and errcode 3034 iret alltraps(): Exiting back into user level process

Stack after trap() returns

alltraps(): exiting 3004 alltraps: ... 3020 # Call trap(tf), where tf=%esp 3021 pushl %esp 3022 call trap 3023 addl $4, %esp 3024 3025 # Return falls through to trapret... 3026 .globl trapret 3027 trapret: 3028 popal 3029 popl %gs 3030 popl %fs 3031 popl %es 3032 popl %ds 3033 addl $0x8, %esp # trapno and errcode 3034 iret Restore all registers Exit into user iret

We're back to where we started, but in a new process

Summary We switch between processes now

Thank you