Presentation is loading. Please wait.

Presentation is loading. Please wait.

Module 1 – Introduction/OS Overview Reading: Chapter 1 and 2 (Silberchatz) Objective:  Quick overview of computer system organization – the processor.

Similar presentations


Presentation on theme: "Module 1 – Introduction/OS Overview Reading: Chapter 1 and 2 (Silberchatz) Objective:  Quick overview of computer system organization – the processor."— Presentation transcript:

1 Module 1 – Introduction/OS Overview Reading: Chapter 1 and 2 (Silberchatz) Objective:  Quick overview of computer system organization – the processor (CPU), memory, and input/output, architecture and general operations.  Introduce operating systems to understand its role and principal functions.

2 Computer System Organization Operating System

3 Computer System Organization Operating System Hardware CPU Bus Device Controllers Memory

4 Computer System Organization  Computer-system operation  One or more CPUs, device controllers connected through common bus providing access to shared memory  Concurrent execution of CPUs and devices competing for memory cycles

5 Computer System Organisation Operating System Hardware CPU Bus Device Controllers Memory Storage Structure Main Memory Secondary Storage

6 Storage Structure  Primary storage  Main memory, directly accessible by the CPU  Program must be in main memory in order to be executed  Main memory usually not large enough to hold all programs and data  Main memory is volatile – loses contents on power loss/reboot  Secondary storage  holds large quantities of data, permanently  In general, we have a hierarchy of storage devices varying by speed, cost, size and volatility

7 Storage-Device Hierarchy

8 Computer System Organisation Operating System Hardware CPU Bus Device Controllers Memory Storage Structure I/O Structure Main Memory Secondary Storage Direct I/O Interrupt Driven DMA

9 I/O Structure  Controller has registers for accepting commands and transferring data (i.e. data-in, data-out, command, status)  Device driver for each device controller talks to the controller  The driver is the one who knows details of controller  Provides uniform interface to kernel  I/O operation  Device driver loads controller registers appropriately  Controller examines registers, executes I/O

10 I/O Structure  How does the driver know when the I/O completes?  Periodically read the status register Called direct I/O Low overhead if I/O is fast If I/O is slow, lots of busy waiting  Any idea how to deal with slow I/O?  Do something else and let the controller signal device driver (raising an interrupt) that I/O has completed Called interrupt-driven I/O More overhead, but gets rid of busy waiting

11 Interrupt Timeline

12 I/O Structure  Interrupt – driven I/O still has lots of overhead if used for bulk data transfer  An interrupt for each byte is too much  Ideas?  Have a smart controller that can talk directly with the memory  Tell the controller to transfer block of data to/from memory  The controller raises interrupt when the transfer has completed  Called Direct Memory Access (DMA)

13 How a Modern Computer Works

14 Computer System Organisation Operating System Hardware CPU Bus Device Controllers Memory Storage Structure I/O Structure Architecture Main Memory Secondary Storage Direct I/O Interrupt Driven DMA Single * processor Multi processor Clusters Distributed

15 Computer-System Architecture  Single-processor system  From PDAs to mainframes  Almost all have special-purpose processors for graphics, I/O Not considered multiprocessor  Multi-processor systems  Increase throughput  Economy of scale  Increased reliability  Asymmetric multiprocessing Each processor assigned a specific task  Symmetric multiprocessing (SMP) most common All processors perform tasks within the OS  Clusters, distributed systems

16 Computer System Organisation Operating System Hardware CPU Bus Device Controllers Memory Storage Structure I/O Structure Architecture Main Memory Secondary Storage Direct I/O Interrupt Driven DMA Single * processor Multi processor Clusters Distributed User View What is it? Services User Interface GUI or CLI

17 The Role of the Operating System

18 User View of a Computer  This is my box, only I am using it  i.e. desktop system with one user monopolizing its resources  OS maximizes the work (or play) user is performing  OS designed mostly for ease of use, not for resource utilization  Handheld systems – usability + low hardware demands  This is The Big Holy Computer, I am blessed to get some CPU time  i.e. mainframe or minicomputer  OS is designed to maximize resource use (CPU, memory, I/O)  Communism in practice - Let’s share our computers  i.e. workstations connected to networks of servers  Dedicated and shared resources  OS compromises between individual usability and resource utilization  What? There is a computer inside?!  Embedded systems designed to run without user intervention

19 Why Operating Systems? If there are several users/applications sharing the computer  i.e. Big Holy Computer  who should get which resources? when?  what is each user/application allowed to do?  how should we bill the users? Ok, ok, if there are many users/programs, something has to manage them, but what if there is single user? (i.e. for my desktop/PDA)?  hardware abstraction  I might still want to run several applications concurrently

20 What Operating Systems Do?  Give me a 1-2 sentence summary of what OS does  OS is program most involved with the hardware hardware abstraction  OS is a resource allocator Manages all resources Decides between conflicting requests for efficient and fair resource use  OS is a control program Controls execution of programs to prevent errors and improper use of the computer

21 Defining Operating Systems  So, what is an operating system?  No universally accepted definition  “Everything a vendor ships when you order an operating system” is good approximation  But varies wildly (see system programs)  “The one program running at all times on the computer” is the one generally used in this course  This is the kernel  Everything else is either a system program (ships with the operating system) or an application program  Ha! What does it mean “running at all times”? When I am playing Tetris, Tetris is running on the CPU, no?

22 System Programs  Are these part of the Operating System?  Whatever is not in the kernel, but is shipped with the OS  Of course, depends on the OS and the vendor  Provide a lot of system-type functionality, i.e. most commands you type in Unix CLI are not shell commands, but standalone system programs that perform system tasks  Most users’ view of the operation system is defined by system programs, not the actual system calls

23 System Programs  System programs provide a convenient environment for program development and execution. They can be divided into:  File management – i.e. copy, rm, ls, mkdir  Status information – i.e. ps, who, regedit  File modification - editors  Programming language support – i.e. cc, javac  Program loading and execution – loaders, debuggers  Communications – ssh, ftp  Application programs – browsers, spreadsheets, games Also called system utilities

24 Operating System Services Services provided to user programs:  I/O operations User program cannot directly access I/O hardware, OS does the low level part for them  Communications Both inter-process on the same computer, and between computers over a network via shared memory or through message passing  Error detection Errors do occur: in the CPU and memory hardware, in I/O devices, in user programs OS should handle them appropriately to ensure correct and consistent computing Low level debugging tools really help

25 Operating System Services (Cont.) Services for ensuring efficient operation of the system itself  Resource allocation and management Needed when there are multiple users/ multiple jobs running concurrently Some resources need specific management code CPU cycles, main memory, file storage Others can be managed using general code - I/O devices  Accounting Which users use how much and what kinds of computer resources  Protection and security Between different processes/users in the computer From the outsiders in a networked computer system Protection: ensuring that all access to system resources is controlled Security: user authentication, defending against external I/O devices from invalid access attempts

26 OS interface for users - CLI Command Line Interface allows direct command entry from keyboard  Command interpreter is itself a program that reads command lines typed in by the user Often called a shell (UNIX terminology)  Execution of commands accomplished in one of two ways The command interpreter executes the command itself Programming instructions allow command interpreters to execute “shell” programs The command is used to invoke a separate program (system program)

27 OS interface for users - GUI  User-friendly desktop metaphor interface  Usually mouse, keyboard, and monitor  Icons represent files, programs, actions, etc  Various mouse buttons over objects in the interface cause various actions (provide information, options, execute function, open directory  Invented at Xerox PARC  Many systems now include both CLI and GUI interfaces  Microsoft Windows is GUI with CLI “command” shell  Apple Mac OS X as “Aqua” GUI interface with UNIX kernel underneath and shells available  Solaris and Linux are CLI with optional GUI interfaces (Java Desktop, KDE)

28 CLI vs GUI So, which one is better?  What would your grandma prefer?  True hacker would never use GUI!  By definition, anybody using GUI is wimp, not a true hacker!  Depends on what you want to do… GUI benefits  Intuitive, easy to use  Ha! If well designed…not always. CLI benefits  Easier to execute complex commands

29 OS Interfaces  CLI and GUI – interfaces for the user  What other interfaces the Operating Systems have?  Interface to the programs running on the computer and requesting OS services System Call interface  Interface to the hardware Interrupts, drivers device controllers  Shall talk about the System Call interface a little later  We will talk about the interface to the hardware in Ch13 - Kernel I/O subsystem

30 Computer System Organisation Operating System Hardware CPU Bus Device Controllers Memory Storage Structure I/O Structure Architecture Main Memory Secondary Storage Direct I/O Interrupt Driven DMA Single * processor Multi processor Clusters Distributed User View What is it? Services User Interface GUI or CLI Operation Dual Mode Process Manag. Memory Management Input/Output Management

31 A Short History of Operating Systems  Problem in 60’s  Computers expensive, need to efficiently utilize them  Single job cannot efficiently use the computer CPU idle when doing I/O, I/O devices idle when computing  Solution:  Multiprogramming  Keeping several jobs in memory in order to efficiently utilize resources  One job selected and run via job scheduling  When it has to wait (for I/O for example), OS switches to another job  In general, no guarantee of low response time

32 A Short History of Operating Systems  Later on: computers becoming cheaper, but many resources still expensive (fast laser printers, mass storage, …)  Share the resources in the network  Every user wants to have fast interactive environment  Solution:  Timesharing (multitasking):  Switch jobs frequently, even if they would like to compute more (preemption)  Timer interrupts are used for preemption  If several jobs ready to run at the same time  CPU scheduling

33 A Short History of Operating Systems  Lots of stuff invented to make this work well  If processes don’t fit in memory, swapping moves them in and out  Virtual memory allows execution of processes not completely in memory  Introduced in 60’s and 70’s for mainframes  Early PCs started simple and primitive (MS- DOS)  Advanced stuff added later as computing power and user requirements grew

34 Operating-System Operations  OS is interrupt driven  Interrupts raised by hardware and software  Mouse click, division by zero, request for operating system service  Timer interrupt (i.e. process in an infinite loop), memory access violation (processes trying to modify each other or the operating system)  Some operations should be performed only by a trusted party  Accessing hardware, memory-management registers  A rogue user program could damage other programs, steal the system for itself, …  Solution: dual-mode operation

35 Transition from User to Kernel Mode  Dual-mode operation allows OS to protect itself and other system components  User mode and kernel mode  Mode bit provided by hardware Provides ability to distinguish when system is running user code or kernel code Some instructions designated as privileged, only executable in kernel mode System call changes mode to kernel, return from call resets it to user

36 System Calls  Programming interface to the services provided by the OS  Process control i.e. launch a program  File management i.e. create/open/read a file, list a directory  Device management i.e. request/release a device  Information maintenance i.e. get/set time, process attributes  Communications i.e. open/close connection, send/receive messages

37 System Calls  Typically written in a high-level language (C or C++)  Called from user program by invoking trap instruction  Software interrupt that sets the mode bit to kernel mode and jumps to the appropriate routine, chosen from the system call table based on the provided trap number Linux example: s.html  Upon completion, the mode is switched back to user mode and status of the system call and any return values are returned

38 API – System Call – OS Relationship

39 System Calls  Mostly accessed by programs via a high-level Application Program Interface (API) rather than direct system call use  Three most common APIs:  Win32 API for Windows  POSIX API for POSIX-based systems UNIX, Linux, and Mac OS X  Java API for the Java virtual machine (JVM)  The caller need know nothing about how the system call is implemented  Just needs to obey API and understand what OS will do as a result call  Most details of OS interface hidden from programmer by API Managed by run-time support library (set of functions built into libraries included with compiler)

40 Standard C Library Example  C program invoking printf() library call, which calls write() system call

41 Process Management  Program is passive, process is active, unit of work within system  Single-threaded process has one program counter specifying location of the next instruction to execute  Process executes instructions sequentially, one at a time, until completion  Multi-threaded process has one program counter per thread  Typically system has many processes, some user, some operating system, running concurrently on one or more CPUs  Process needs resources to accomplish its task  CPU, memory, I/O, files  Initialization data  When process terminates, its resources need to be reclaimed  OS needs to facilitate interaction between processes

42 Process Management Activities  The operating system is responsible for the following activities in connection with process management:  Creating and deleting both user and system processes  Suspending and resuming processes  Providing mechanisms for process synchronization  Providing mechanisms for process communication  Providing mechanisms for deadlock handling

43 Computer Startup and Execution  How does a computer start?  bootstrap program is loaded at power-up or reboot  Typically stored in ROM or EEPROM, generally known as firmware  Basic hardware initialization (CPU registers, memory)  Loads operating system kernel and starts execution  How does execution look like?  Typical situation: User program runs, kernel waits for an event to occur  Interrupt from either hardware or software Hardware can trigger an interrupt at any time Software triggers interrupt by executing system call  Stops current execution, transfers execution to a fixed location Interrupt service routine is executed, then the execution is resumed where it was interrupted Usually a service routine for each device / function Interrupt vector dispatches interrupt to appropriate routine

44 Example: MS-DOS execution (a) At system startup (b) running a program  Simple, single-user process control

45 Example: Unix Shell  When you log in, a shell program is launched for you  Shell interprets the command line and launches the programs you specify  So, what happens when you type mkdir rrr and press enter?  The shell asks the system to launch a program called ‘mkdir’ with command line argument ‘rrr’  It actually has to figure out where is that program located …  … and then tell the kernel to launch it  In Unix, the launching of a program is actually two-step process:  fork() system call to make a new process - copy of itself  exec() system call to replace the shell body of this new process by the body of the program  We will talk about this in detail when discussing process management

46 Example: Unix Shell  The ‘mkdir’ program creates a directory ‘rrr’ and returns exit status to the parent process (i.e. the shell) by making system call exit()  Now, what is the shell process doing meanwhile?  By default: waiting until the launched process finishes Launching foreground process  But you can also launch a process in the background – in such case the shell continues immediately

47 Memory Management  Program being executed needs its data and instructions in the main memory  We want to execute several programs concurrently, possibly with memory requirements larger than the available physical memory  Memory management determines what is in memory and when.  Goal: optimizing CPU utilization and computer response to users  Memory management activities  Keeping track of which parts of memory are currently being used and by whom  Deciding which processes (or parts thereof) and data to move into and out of memory  Allocating and de-allocating memory space as needed

48 Storage Management  OS provides uniform, logical view of information storage  Abstracts physical properties to logical storage unit - file  Each medium is controlled by device (i.e. disk drive, tape drive) Varying properties include access speed, capacity, data- transfer rate, access method (sequential or random)  File-System management  Files usually organized into directories  Access control on most systems to determine who can access what  OS activities include Creating and deleting files and directories Primitives to manipulate files and directories Mapping files onto secondary storage Backup files onto stable (non-volatile) storage media

49 Mass-Storage Management  Usually disks used to store what won’t fit in memory  Proper management is of central importance  Entire speed of computer operation hinges on the disk subsystem and its algorithms  OS activities  Free-space management  Storage allocation  Disk scheduling  Some storage need not be fast  Tertiary storage includes optical storage, magnetic tape  Still must be managed  Varies between WORM (write-once, read-many- times) and RW (read-write)

50 Caching  Important principle, performed at many levels in a computer (in hardware, operating system, software)  Information in use copied from slower to faster storage temporarily  Faster storage (cache) checked first to determine if information is there  If it is, information used directly from the cache (fast)  If not, data copied to cache and used there  Cache is smaller than storage being cached  Cache management important design problem  Cache size and replacement policy  Why caching works?  Principle of locality (temporal, spatial)

51 Performance of Various Levels of Storage  Movement between levels of storage hierarchy can be explicit or implicit

52 I/O Subsystem  One purpose of OS is to hide peculiarities of hardware devices from the user  I/O subsystem responsible for  Memory management of I/O including buffering (storing data temporarily while it is being transferred)  Caching (storing parts of data in faster storage for performance)  Spooling (the overlapping of output of one job with input of other jobs)  General device-driver interface  Drivers for specific hardware devices

53 Migration of Integer A from Disk to Register  Multitasking environments must be careful to use most recent value, does not matter where it is stored in the storage hierarchy  Multiprocessor environments usually provide cache coherency in hardware such that all CPUs have the most recent value in their cache  Distributed environment situation even more complex  Several copies of a datum can exist

54 A Kernel I/O Structure

55 Computer System Organisation Operating System Hardware CPU Bus Device Controllers Memory Storage Structure I/O Structure Architecture Main Memory Secondary Storage Direct I/O Interrupt Driven DMA Single * processor Multi processor Clusters Distributed User View What is it? Services User Interface GUI or CLI Operation Dual Mode Process Manag. Memory Management Input/Output Management Different Flavors Design issues Structure Layer Micro Kernel Modules Virtual Machine

56 Operating System Design and Implementation  The design is primarily affected by choice of hardware and the type of system  Batch, time-shared, single-user, multi-user, distributed, real-time, general purpose  User goals and System goals  User goals – operating system should be convenient to use, easy to learn, reliable, safe, and fast  System goals – operating system should be easy to design, implement, and maintain, as well as flexible, reliable, error-free, and efficient  Implementation  Traditionally in assembler  Nowadays mostly in C, with small assembler sections (drivers, saving/restoring registers)

57 Operating System Structure  Internal structure of different OSes can vary widely  As the requirements vary widely  Low hardware resources, simple functionality  Simple, monolithic structure  More functionality & resources  Layered structure  MSDOS and traditional Unix are OS-es with monolithic structure that uses some layering  Even more functionality & resources, focus on clean design and flexibility  Microkernel structure (MACH, QNX, early Windows NT)  Flexibility & efficiency  Modular structure (Solaris, Windows NT)

58 MS-DOS Layer Structure

59 Layered Approach  The operating system is divided into a number of layers (levels), each built on top of lower layers. The bottom layer (layer 0), is the hardware; the highest (layer N) is the user interface.  With modularity, layers are selected such that each uses functions (operations) and services of only lower-level layers

60 Traditional UNIX System Structure  UNIX was created as a simple, relatively low functionality alternative to the complex mainframe OS- es of that time

61 Microkernel System Structure  Moves as much from the kernel into “user” space  Communication takes place between user modules using message passing  Benefits:  Easier to extend a microkernel  Easier to port the operating system to new architectures  More reliable (less code is running in kernel mode)  More secure  Detriments:  Performance overhead of user space to kernel space communication

62 Modules  Most modern operating systems implement kernel modules  Uses object-oriented approach  Each core component is separate  Each talks to the others over known interfaces  Each is loadable as needed within the kernel

63 Virtual Machines  A virtual machine takes the layered approach to its logical conclusion. It treats hardware and the operating system kernel as though they were all hardware  A virtual machine provides an interface identical to the underlying bare hardware  The VM creates the illusion of multiple processes, each executing on its own processor with its own (virtual) memory

64 System Models (a) Nonvirtual machine (b) virtual machine Non-virtual Machine Virtual Machine

65 Virtual Machines - Implementation  How to create several VM when we have only one set of hardware resources?  Sharing resources  CPU  Time-shared scheduling  Printers/card readers  Spooling  Memory  Virtual memory  HD  Ha! Its not possible to have full HD for each VM!  Other problems: real-time aspects

66 Advantages/Disadvantages of Virtual Machines Advantage:  Complete protection/isolation of system resources between VMs  Perfect vehicle for operating-systems research and development If the OS you are developing crashes, just restart the VM  Useful when you have applications for different OSs Disadvantage  No direct sharing of resources between different VMs  Difficult to implement completely

67 Example: VMware Architecture

68 The Java Virtual Machine

69 We are not going to talk about  Distributed systems  Real-time embedded systems  Multimedia systems  Handheld systems  Different computing environments  Peer to peer computing  Web-based computing

70 Computer System Organisation Operating System Hardware CPU Bus Device Controllers Memory Storage Structure I/O Structure Architecture Main Memory Secondary Storage Direct I/O Interrupt Driven DMA Single * processor Multi processor Clusters Distributed User View What is it? Services User Interface GUI or CLI Operation Dual Mode Process Manag. Memory Management Input/Output Management Different Flavors Design issues Structure Layer Micro Kernel Modules Virtual Machine


Download ppt "Module 1 – Introduction/OS Overview Reading: Chapter 1 and 2 (Silberchatz) Objective:  Quick overview of computer system organization – the processor."

Similar presentations


Ads by Google