Multiprocessor OS types

Multiprocessor OS types

1. Each CPU has its own OS

   • Statically divide memory into as many partitions as there are CPUs and give each CPU its own private memory and its own private copy of the operating system.   In effect each CPU operates as independent computer. 
   • Optimization is to allow all the CPUs to share the operating system code and make private copies of only the operating system data structures.
   • Four aspects of this model: 1-When a process makes a system call , the system call is caught and handled on its own CPU using the data structure in that operating system's tables. 2-There is no sharing of processes, it can happen that CPU 1 is idle while CPU 2 is loaded with work. 3-There is on sharing of physical pages. There is no way for CPU2 to borrow some pages from CPU1 since the memory allocation is fixed. 4-If the OS maintain a buffer cache of recently used disk blocks, each OS does this independently of the other ones. To avoid it eliminate the buffer cache which affects the performance. 

2. Master-Slave Multiprocessors

   • One copy of the OS and its tables is present on CPU 1 and not on any of the others. All system calls are redirected to CPU 1 for processing there. 
   • This model solves most of the first model issues: 1- Single data structure that keeps track of ready processes. When a CPU goes idle, it asks the operating system on CPU 1 for a process to run and is assigned one, thus it can never happen that one CPU is idle while another is overloaded. 2-Pages can be allocated  among all the processes dynamically and there is only one buffer cache, so inconsistencies never occur.  
   • The problem with this model is that with many CPUs, the master will become a bottelneck. After all it must handle all system calls from all CPUs. Thus this model is simple and workable for small multiprocessors but for large ones it fails. 

3. Symmetric Multiprocessors

   • There is one copy of the OS in memory, but any CPU can run it. When a system call is made, the CPU on which the system call was made traps to the kernel and processes the system call.
   • Problems:  If two or more CPUs are running operating system code at the same time, disaster may well result. Associate mutex with the operating system, making the whole system first acquire the mutex. If the mutex is locked it just waits. In this way any CPU can run the operating system, but only one at a time. This approach is somethings called a big kernel lock.
   • We still can have a long CPU queues waiting to get in. soln: Many parts of the operating system are independent of one another. One CPU running the scheduler, another running file-system. Splitting the OS up into multiple independent critical regions that do not interact with one another. Each critical region is protected by its own mutex, so only one CPU at a time can execute it. 
   • The hard part of splitting the OS into critical regions that can be executed concurrently by different CPUs without interfering with one another, not even in subtle, indirect ways.
   • Multiprocessor Synchronization
     • The TSL must first lock the bus, preventing other CPUs from accessing it, then do both memory accesses, then unlock the bus.