Class 14
CS 372H
03 March 2011

On the board
------------

1. OS organization
2. Midterm
3. Scheduling intro
    --when, what metrics
    --next time: disciplines; lessons and conclusions

---------------------------------------------------------------------------

1. OS organization

    --What is a microkernel? Here's the idea:

	--Implement many traditional OS abstractions in user-space servers

	    --Paging, file system, networking, possibly even interrupt
	    handlers (like L3), print, display

	    --Some servers have privileged access to some h/w (e.g., file
	    system and disks)

	--What does kernel do? Minimum to support servers:

	    --address spaces

	    --threads (maybe)

	    --inter-process communication (IPC)

	    --some IPC handle which can send/receive messages.

	--Everything works through message passing
	    --apps talking to servers
	    --apps talking to apps
	    --servers talking to servers

    --Advantages:
	 --Modularity and extensibility (understandable, replaceable services)
	 --Isolation (bugs take down the server, not the kernel)
	 --Fault-tolerant (same reason: just restart individual services)
	 --Easier to extend to distributed context (send/recv no
	    different in terms of interface, just implementation)

    --History

	--individual ideas around since the beginning

	--lots of research projects starting early 1980s

	--hit the big time w/ CMU's Mach in 1986

	--thought to be too slow in early 1990s (Mach very slow; people
	concluded microkernels are a bad idea)

	--now slowly returning (OSX, QNX in embedded systems/routers, etc)

	--ideas very influential on non-microkernels

    --What is disadvantage? 
	
	--Performance

	    --What would be simple calls into the kernel are now IPCs
	    
	    --How bad is performance? (Cost of context switches: TLB
	    flush, etc.
	    
		--Why don't normal syscalls have to pay for this?

	--Programmability

	    --Ken Thompson: "I would generally agree that microkernels
	    are probably the wave of the future. However, it is in my
	    opinion easier to implement a monolithic kernel. It is also
	    easier for it to turn into a mess in a hurry as it is
	    modified." 

    --More about the trade-off:

	--monolithic makes it easier to have sub-systems cooperate (such
	as the pager and the file system; these modules can read each
	other's data structures)

	--monolithic creates lots of strange interactions, which leads
	to complexity and bugs

    --In practice...

	--huge issue: Unix compatibility

	--critical to widespread adoption

	--difficult: Unix was not designed in a modular fashion

	--Mach, L4: one big Unix server ... which is not
	a huge practical difference from a single Linux kernel (who
	cares if it's running in user space? a single bug still takes
	down all of the interesting state because it's all in that Unix
	server).

    --Plus microkernels might not actually be smaller, despite their
    more limited function

	--Unix V6 was 9000 lines of code

	--Plan 9 is also very small and is monolithic

    --So the approaches to kernel design are:

	1. Monolithic (Linux, Unix, etc.).
	    --philosophy:
		--convenience (for application or OS programmer)
		--for any problem, either hide it from the application,
		or add a new system call
	    --very successful approach

	2. Microkernel (OSX, L3, etc.)
	    --philosophy:
		--IPC and user-space servers
		--for any problem, make a new server, and talk to it
		with RPC or IPC [but that doesn't actually solve the
		problem....]

	3. Exokernel (JOS!)
	    --philosophy:
		--eliminate all abstractions
		--for any problem, expose hardware or the needed
		information to the application, and let the application
		do what it wants

    --Examples of exokernel use are:

	--Let application built nice address space if it wants, or not

	    --Expose calls like:
		pa = AllocPage()
		DeallocPage(pa)
		MapPage(va, pa)

	    --And expose upcalls like:
		PageFault(va)

	    --Kernel's job is only:
	    
		--to ensure that app creates mappings to physical pages
		that it owns

		--to track which environment owns which physical pages

		--decide which application to reclaim pages from, if
		system runs out

	--What does it mean to expose CPU to app?
	    --Tell application when it is about to be context-switched
	    *out*
	    --Tell application when it is about to be context-switched
	    *in*

	    then, on a timer interrupt:
		--cpu jumps from application into kernel
		--kernel issues please_yield() upcall:
		    --then app saves state (registers, etc.)
		    --app calls yield() for real
	    
	    when kernel decides to resume application:
		--kernel jumps into the application at the "resume()"
		upcall. application then restores its saved registers

	    example use:
		--suppose time slice ends in the middle of

		    acquire(&mutex)
		    ....
		    release(&mutex)
    
		--then, inside please_yield(), app can complete the
		critical section and release the mutex

		--NOTE: we don't recommend this (not least because it
		violates the concurrency commandments). we include it
		to show you an example use; we're not saying it's a
		*good* use.

    --**JOS is an exokernel!**

    --To summarize:

	--monolithic makes it easier to have sub-systems cooperate (such
	as the pager and the file system; these modules can read each
	other's data structures)

	--monolithic creates lots of strange interactions, which leads
	to complexity and bugs

2. Midterm

    A. Review session on Monday

    B. Content

	--covers readings (book, papers), labs, lectures, homeworks

	--through Tuesday's class

	--question format:
	
	    --short answers

	    --design

	    --coding

    C. Ground rules

	--75 minutes

	--bring ONE two-sided sheet of notes; formatting requirements
	listed on Web page

	--no electronics: no laptops, cell phones, PDAs, etc.

    D. Advice

    --we want you all to do well!

    --please don't go overboard studying. on the other hand, if you
    haven't been keeping up, or you don't study, you may find the exam
    very difficult.

3. scheduling intro

    A. When do scheduling decisions happen?

	[draw picture]

	scheduling decisions take place when a process:

	    (i) Switches from running to waiting state 
	    (ii) Switches from running to ready state 
	    (iii) Switches from waiting to ready 
	    (iv) Exits 

	preemptive scheduling: at all four points

	nonpreemptive scheduling: at points (i), (iv), only (this is the
	definition of nonpreemptive scheduling)

    B. What are metrics and criteria?
    
	--system throughput
	    # of processes that complete per unit time

	--turnaround time
	    time for each process to complete

	--response time
	    time from request to first response (e.g., key press to
	    character echo, not launch to exit)

	--fairness
	    different possible definitions:
		--freedom from starvation
		--all users get equal time on CPU
		--highest priority jobs get most of CPU
		--etc.
	    [often conflicts with efficiency. true in life as well.]

	the above are affected by secondary criteria:

	--CPU utilization (fraction of time CPU is actually working)

	--waiting time (time each process waits in ready queue)

    Next time: context switching costs and different scheduling
    disciplines