CSci 430: Programming Project

Operating Systems, Stallings

Chapter 10 notes

CSci 430 Spring 2019

Overview

Though the addition of more than 1 CPU into a system does introduce some new issues to be considered when scheduling processes, the basic mechanisms and analysis of process scheduling are not so di�erent as you might think. Section 10.1 of our textbook covers 3 main categories of multiprocessor sys- tems:

1. Loosely coupled or distributed memory cluster systems

2. Functionally specialized processors

3. Tightly coupled, shared memory multiprocessors.

Of the three categories, the third category is the most familiar one to most of the students of this course. Modern general purpose computing sys- tems often have multi-core chips and/or 2 or more CPU chips as part of the system. However, all of the CPUs on such multi-core chips are functionally equivalent. Modern general purpose personal computers actually often do have a specialized CPU, di�erent from the general purpose CPUs. This is the CPU in your graphical processor or graphics card. However, usually the OS does not schedule work or processes to be run on this CPU, instead the video graphics drivers use this specialized CPU to perform rendering and display driver tasks. The �rst category, scheduling on a distributed memory cluster system, is an issue very important to modern supercomputing clus- ter systems. Most supercomputers used in scienti�c research are what are known as commodity computing clusters. They are basically a collection of large numbers of standard computers, connected together using high-speed networking connections. Unlike your personal computer or laptop, all of the computers in such a cluster computer have their own set of memory, thus

1

they are often referred to as distributed memory systems, in contrast to your typical personal computer that has multiple CPUs sharing a common pool of RAM memory. In this course, we will concentrate on the issues of processor scheduling for shared memory multiprocessor systems, but you should read the materials about the other 2 categories of systems as well in section 10.1 of our textbook.

One important consideration when scheduling processes on a multi-processor system, is how to assign processes to available processors. The simplest ap- proach is to treat all of the CPUs as an available pool of processors, and assign processes to processors on demand. The question arrises at this point of whether, when a process starts running on a CPU, the assignment should be static or dynamic.

The static vs. dynamic decision can have consequences. In a multi-core CPU chip, the cores have local cache memory that are often separate, or not shared, among the cores (The Level 1 L1 and/or L2 cache levels). When a process runs on a CPU, it begins using the cache memory local to that CPU core. So, if we use dynamic scheduling, the process could be assigned and run on a di�erent core at a later time. However, this has the disadvantage that all of the loaded cache data becomes invalid, once the process is switched to another core. This can be ine�cient, as all of the cache pages will end up being needed to be reloaded once again on the new core L1 cache. However, static assignment has its own problems. In static assignment, once a process begins using a particular core, we don't switch it to use another core. The obvious problem occurs if you have 2 very long running processes that get assigned to the same core, they could end up competing to be scheduled on the same core, while other cores go idle, with no statically assigned processes running on them.

This, in a modern OS that handles multi-core scheduling, it is common to see a dynamic allocation implementation. However, normally the pro- cessor scheduler has built-in preferences that cause the processes to greatly prefer to be keep scheduling on the same CPU (known as processor a�nity). Some parameters can be set or tweaked for a running process, to make this a�nity for a particular core be stronger or weaker. This, with this concept of processor a�nity, processes tend to try to execute on the same core they begin working on, but can be switched over to a new core when necessary.

2