Sogang University Advanced Operating Systems (Process Scheduling - Linux) Advanced Operating Systems (Process Scheduling - Linux) Sang Gue Oh, Ph.D.

Sogang University Process Scheduling - Linux Page 2 Scheduling Policy (1)  Scheduling Policy  set of rules to determine when and how to select a new process to run  Traditional Scheduling Objectives  fast process response time  good throughput for background jobs  avoidance of process starvation  reconciliation of the needs of low- and high-priority processes  Linux Scheduling  based on time sharing  CPU time divided into slices – one for each runnable process (quantum)  based on timer interrupt and ranking (or priority)  dynamic process priority – by kernel and by users (via system calls)

Sogang University Process Scheduling - Linux Page 3 Scheduling Policy (2)  System Calls Related to Scheduling System CallsDescriptions nice() Change the priority of conventional process getpriority() Get the maximum priority of a group of conventional processes setpriority() Set the priority of a group of conventional processes sched_getscheduler() Get the scheduling policy of a process sched_setscheduler() Set the scheduling policy and priority of a process sched_getparam() Get the priority of a process sched_setparam() Set the priority of a process sched_yield() Relinquish the processor voluntarily without blocking sched_get_priority_min() Get the minimum priority value for a policy sched_get_priority_max() Get the maximum priority value for a policy sched_rr_get_interval() Get the time quantum value for the Round Robin policy

Sogang University Process Scheduling - Linux Page 4 Scheduling Policy (3)  Process Classification  CPU usage: I/O-bound vs. CPU-bound processes  IO type : interactive vs. batch processes  timing : real-time (1~99) vs. normal processes (0)  I/O-bound processes favored by Linux (or other Unix kernels as well)  Process Preemption  preemptive user processes  current user process interrupted by a new process with higher priority  current user process switched over with quantum expired (need_resched)  non-preemptive kernel processes (schedule( ), interruptable_sleep_on ( ))  no actual real-time support guaranteed

Sogang University Process Scheduling - Linux Page 5 Scheduling Policy (4)  Process Quantum  a time slice during which a process can run on CPU  too short quantum: too much switching overhead  too long quantum: too slow system response time  Linux policy: make it as long as possible while keeping good response time  different from process to process – more or less 60ms in general  example: Linux process 0 – swapper in INIT-TASK macro #define DEF_COUNTER (10 * HZ / 100) // 10 ticks ≈ 105ms where HZ = 100 for IBM compatible PCs

Sogang University Process Scheduling - Linux Page 6 Scheduling Algorithm (1)  Epoch  basic time unit on which Linux scheduling is based  a duration during which each process keeps its time quantum  Scheduling Basics  scheduling based on epoch  a specific time quantum per process within a single epoch  CPU assigned to each process (maybe several times) for the given quantum  the given epoch ends when all runnable processes exhaust their quanta  a new quantum computed and assigned to each runnable process again  base time quantum per process – can be changed via nice() and setpriority()  base time quantum inherited to child processes 

Sogang University Process Scheduling - Linux Page 7 Scheduling Algorithm (2)  Linux Priority Used for Scheduling  static priority assigned by the users for RT processes (1~99) can not be changed by the scheduler  dynamic priority applied to conventional processes base priority + number of ticks left within the given epoch can be changed via system calls such as nice()  static priority > dynamic priority  Scheduling Policy  SCHED_FIFO: for RT processes, FIFO among same priorities  SCHED_RR: for RT processes, RR among same priorities  SCHED_OTHER: for conventional time-shared processes

Sogang University Process Scheduling - Linux Page 8 Scheduling Algorithm (3)  Scheduler  find a process in the runqueue and assign the CPU  invoked directly or lazy (deferred) way  Direct Scheduler Invocation  when a process to relinquish the CPU voluntarily  when the current process must be blocked  by many device drivers  Lazy Scheduler Invocation  when a process needs to be scheduled involuntarily (via setting need_reched field of the current process descriptor)  when the current process’s quantum expires  when a process with the higher priority than the current wakes up  when sched_setscheduler() or sched_yield() is called

Sogang University Process Scheduling - Linux Page 9  Main Goal – Determine Which Process to Run Next  via goodness() function call  input to goodness() p: descriptor pointer of candidate process this_cpu: logical CPU number this_mm: memory descriptor of the process being replaced  return value and meaning weight = -1: SCHED_YIELD flag is set weight = 0: conventional process and quantum expired 2  weight  77 : conventional process and quantum not expired (+15, +1 for kernel thread or memory shared) weight  1000: real-time process p->counter Scheduling Algorithm (4)

Sogang University Process Scheduling - Linux Page 10 Scheduling Algorithm (5)  Scheduling on Multiprocessor Systems  each processor runs its own schedule() function  processors communicate with each other  process can migrate from one processor to another – global priority  reschedule_idle() – sends RESCHEDULE_VECTOR first checks the processor on which the last process ran for availability if not, then tries to find a least recently active idle processor (why?) if not, finds processors running lower priority processor than the one just suspended then, reschedule  Hyper-threading Technology  two threads executed at once by one hyper-threaded microprocessor  multiple copies of the internal registers and switching between register sets

Sogang University Process Scheduling - Linux Page 11 Scheduling Algorithm (6)  Performance of Scheduling Algorithm  very straightforward and easy in Linux  a lot of room for improvement – but no significant success  one good for some cases and another good for other cases  performs good for small and medium scale systems  performs relatively poor for large scale systems  too large time quantum for high-end machines with a very high load  less optimal I/O bound process boosting strategy  weak RT support due to non-preemptive kernel feature  Unscalable – inefficient when the number of processes is large  long time taken to recompute priorities (in every second in Unix)  use long interval between priority recomputations (What happens?)