Advanced Operating Systems - Fall 2009 Lecture 4 – January 21, 2009

1. Advanced Operating Systems - Fall 2009Lecture 4 – January 21, 2009 Dan C. Marinescu Email: dcm@cs.ucf.edu Office: HEC 439 B. Office hours: M, Wd 3 – 4:30.

2. Last, Current, Next Lecture • Last time: • Resource sharing models: multiprogramming and multitasking • Operating Systems Structures • Today: • Butler Lampson’s hints for system design • The complexity of computing and communication systems • State • Processes • Next time: • Threads

3. Lampson: Generality can lead to complexity. • System call implementation in Tenex: • A system call  machine instruction of an extended machine • A reference to an unassigned virtual page causes a trap to the user’s program even if caused by a system call. • All arguments (including strings) to system calls passed by reference. • The CONNECT system call  access to a directory. • One of its arguments a string, the password for the directory. • If the password is wrong the call fails after 3 seconds (why 3s?)

4. The CONNECT system call for i:=0 toLength(directoryPassword)do if directoryPassword[i] ≠passwordArgument[i] then Wait 3 seconds; returnBadPassword; endif endfor connectToDirectory; returnsuccess;

5. How to exploit this implementation to guess the password • If the password: • is n characters long; • a character is encoded in 8 bits; I need in average 256n/2 trials to guess the password. • In this implementation of CONNECT in average I can guess the password in 128n trials. • How? • What is wrong with the implementation.

6. How • Arrange the passwordArgument such that • its first character is the last character of a page • The next page is unassigned. • Try every character allowable in a password as first • If CONNECT returns badArgument  the guess was wrong • If the system reports a reference to an unassigned page  the guess is correct. • Try every character allowable in a password as second…..

7. What is wrong with the implementation? • The interface provided by an ordinary memory reference instruction in system code is complex. • An improper reference is sometimes reported to the user without the system code getting control first.

8. Lampson’s Hints: Interfaces • Separate an implementation of an abstraction from the use of the abstraction. • The implementation may change without affecting those who use it. • Conceal undesirable properties; do not hide the desirable ones. • Keep it simple  • Perfection is achieved not when there is no longer anything to add, but when there is no longer anything to take away (Antoine de Saint-Exupery) • Keep basic interfaces stable

9. Lampson’s Hints: Changes • Balance the desire to improve and the need to stability. • Handle normal cases and worst cases separately.

10. The complexity of computing and communication systems • The physical nature and the physical properties of computing and communication systems must be well understood and the system design must obey the laws of physics. • The behavior of the systems is controlled by phenomena that occur at multiple scales/levels. As levels form or disintegrate, phase transitions and/or chaotic phenomena may occur. • Systems have no predefined bottom level; it is never known when a lower level phenomena will affect how the system works.

11. The complexity of computing and communication systems (cont’d) • Abstractions of the system useful for a particular aspect of the design may have unwanted consequences at another level. • A system depends on its environment for its persistence, therefore it is far from equilibrium. • The environment is man-made; the selection required by the evolution can either result in innovation, generate unintended consequences, or both. • Systems are expected to function simultaneously as individual entities and as groups of systems. • The systems are both deployed and under development at the same time.

12. State • Finite versus infinite state systems • Hardware verification a reality. • Software verification; is it feasible? • State of a physical system • Microscopic • Macroscopic state • State of a processor • State of a program • Snapshots - checkpointing • State of a distributed system – the role of time.

13. Process • Process – a program in execution. • I/O-bound process – spends more time doing I/O than computations, many short CPU bursts • CPU-bound process – spends more time doing computations; few very long CPU bursts • The code and the data manipulated by a process is in: • Memory or cache • the text (code) section • the data section • the contents of the stack • Registers • the program counter • the integer and floating point

14. Process in Memory

15. Process State

16. Process Creation • Parent process create children processes, which, in turn create other processes, forming a tree of processes • Resource sharing • Parent and children share all resources • Children share subset of parent’s resources • Parent and child share no resources • Execution • Parent and children execute concurrently • Parent waits until children terminate

17. Process Creation (Cont.) • Address space • Child duplicate of parent • Child has a program loaded into it • UNIX examples • fork system call creates new process • exec system call used after a fork to replace the process’ memory space with a new program

18. Process Creation

19. C Program Forking Separate Process int main() { pid_t pid; /* fork another process */ pid = fork(); if (pid < 0) { /* error occurred */ fprintf(stderr, "Fork Failed"); exit(-1); } else if (pid == 0) { /* child process */ execlp("/bin/ls", "ls", NULL); } else { /* parent process */ /* parent will wait for the child to complete */ wait (NULL); printf ("Child Complete"); exit(0); } }

20. Examples of system processes in Solaris • Sched the scheduler • pageout manages virtual memory • fsflush manages the file system • Initthe root of all user processes • Inetd  responsible for networking services • telnetdeamon  processes telnet commands • ftpdeamon  processes ftp commands • Csh  command shell • dtlogin  process controlling a login screen • Xsession  process controlling an X-window session • xdt_shell  support for the creation of a csh for login

21. A tree of processes in Solaris

22. Process Termination • Process executes last statement and asks the operating system to delete it (exit) • Output data from child to parent (via wait) • Process’ resources are deallocated by operating system • Parent may terminate execution of children processes (abort) • Child has exceeded allocated resources • Task assigned to child is no longer required • If parent is exiting • Some operating system do not allow child to continue if its parent terminates • All children terminated - cascading termination

23. Process Control Block (PCB) • Process state • Program counter • CPU registers • CPU scheduling information • Memory-management information • Accounting information • I/O status information

24. Process Control Block (PCB)

25. Process scheduling

26. Context Switch • When CPU switches to another process, the system must save the state of the old process and load the saved state for the new process • Context-switch time is overhead; the system does no useful work while switching • Context switch time dependent on hardware support

27. Processes migrate among the several queues • Job queue all processes in the system • Ready queue processes residing in main memory, ready and waiting to execute • Device queues processes waiting for an I/O device

28. Schedulers • Long-term scheduler (job scheduler) – selects processes to be brought into the ready queue. • Controls the degree of multiprogramming. • Invoked infrequently (seconds, minutes)  (may be slow) • Short-term scheduler (CPU scheduler) – selects the process to be executed next. • Invoked frequently (milliseconds)  (must be fast) • Time slice. Relation of the time slice with the context switch time. • Medium-term scheduler – selects processes to be swapped in/out (added/removed) from the ready queue.

29. Medium Term Scheduler

30. A scheduling exercise A system uses a scheduling strategy called Processor Sharing (PS) a hardware supported context switch occurs after each instruction and the switching overhead is zero. • If a process needs T seconds to finish in the absence of competition how much time it takes to finish when the PS strategy involves n processes? • What hardware features in addition to zero-overhead context switching are necessary to support such a scheduling strategy?

31. Linux O(1) scheduler • Schedules processes in constant time, independent of the number of processes • Minimizes jitterimportant for real time systems • Efficiency: • Balance the scheduling overhead versus the time a process is allowed to run. • Interactivity requires fast response time and reduces efficiency. Difficult to accommodate both server and desktop environments. • Only one central tunable, /proc/sys/kernel/sched_granularity_ns, which can be used to tune the scheduler from 'desktop' (low latencies) to 'server' (good batching) workloads.

32. Linux O(1) scheduler (cont’d) • Fairness and starvation; a process about to starve, should get a priority boost, and/or immediate preemption. • Adaptation of an algorithm used in packet scheduling in networks. • SMP scheduling (symmetric multi-processing) • Which processor to allocate? • Cache considerations – schedule the same task to the same CPU as often as possible. • Eg. Intel Hyperthreading • NUMA scheduling (non-uniform memory access systems)

33. Real-time schedulers • Hard /soft deadlines • Preemption • Priority inversion  a low priority process holds a shared resource required by a high priority process. This causes the execution of the high priority process to be blocked until the low priority one releases the resource, effectively "inverting" the relative priorities of the two processes. If a medium priority process, which does not require the shared resource, attempts to run in the interim, it will take precedence over the low priority and the high priority processes.