CSC 369 TUTORIAL 6 MIDTERM REVIEW TA Trevor

Ø This is a test. bits for page number = 22 bit virtual address

phys addr 0 x 2 CF 070 is physical frame 0 x 2 C

Answer: PAGING MEMORY Allocation and fragmentation

SYNCHRONIZATION Unprotected counter increments

Are there any data races in this code? If so: how can they occur,

Answer: Suppose throwing 128 CPUs at this code doesn’t improve performance much. Why would

Answer: Basically: The running time of show_money is tiny, compared thread creation time, and

Ø Consider a 2 -level MLFQ: Ø Level 0 (L 0): round-robin with quantum=2

CPU/THREAD SCHEDULING Multi-level Feedback Queue (MLFQ)

Slides: 13

Download presentation

CSC 369 – TUTORIAL 6: MIDTERM REVIEW TA: Trevor Brown Slides: http: //www. cs. utoronto. ca/~tabrown/csc 369/week 6. ppt

PAGING MEMORY

Ø This is a test. bits for page number = 22 bit virtual address - 16 bits offset (for 64 k page size) = 6, so number of pages is 2^6 or 64. vaddr 0 x 03 BEEF is vpn 0 x 03 with offset 0 x. BEEF. Page table for virtual page number (vpn) 3 is frame 0 x. F 0, so phys addr is 0 x. F 0 BEEF PAGING MEMORY Address Translation

phys addr 0 x 2 CF 070 is physical frame 0 x 2 C with offset 0 x. F 070. Searching the page table, we find frame 0 x 2 C is allocated for virtual page number 1, so vaddr is 0 x 01 F 070 if physical address are 32 bits, and we still need 16 bits for offset, then there are 16 bits for physical page number, giving 2^(16) = 64 k physical page frames extra time to look up entries in page tables (extra memory accesses) or extra memory space to store page tables for translation PAGING MEMORY Address Translation (continued)

Answer: PAGING MEMORY Allocation and fragmentation

SYNCHRONIZATION

SYNCHRONIZATION Unprotected counter increments

Are there any data races in this code? If so: how can they occur, and how can we fix them? SYNCHRONIZATION Data races

Answer: Suppose throwing 128 CPUs at this code doesn’t improve performance much. Why would that be the case? SYNCHRONIZATION Data races (continued)

Answer: Basically: The running time of show_money is tiny, compared thread creation time, and we can only create one thread at a time. (show_money is only a few instructions) Lesson: Concurrent jobs have to be substantial enough to warrant thread creation. SYNCHRONIZATION Data races (continued)

CPU/THREAD SCHEDULING

Ø Consider a 2 -level MLFQ: Ø Level 0 (L 0): round-robin with quantum=2 Ø Level 1 (L 1): first-come-first-served Ø New processes go to back of L 0. Ø Processes finished I/O burst go to back of L 0. Ø The workload: Ø Three processes (P 0, P 1, P 6) spawn at times 0, 1, 6. Ø Each process does: Ø CPU burst for 5 Ø I/O burst for 3 Ø CPU burst for 1 Ø The problem: for the first 20 time units, for each process, write one of the following: [blank], new, [has] CPU, [is] preempt[ed], [is on queue] L 0 / L 1 / IO, exit. CPU/THREAD SCHEDULING Multi-level Feedback Queue (MLFQ)

CPU/THREAD SCHEDULING Multi-level Feedback Queue (MLFQ)