The Linux Scheduler

Objectives

We would like to :

Discuss the operation of the Linux scheduler.

Notes

This is section 5.7.1
Linux has been through a series of scheduler changes
- The UNIX scheduler
- A scheduler called O(1) ( 2.6 kernel 2003)
  - Named because time was constant WRT the number of processes to be scheduled.
  - SMP, processor affinity, load balancing
  - Response time proved to be poor for interactive systems.
- CFS: Completely fair scheduler. (2.6.23 kernel 2007) reference
- There were changes to the CFS over time.
- EEVDF, Earliest Eligible Virtual Deadline First (2023/24, 6.6 kernel) reference, or another
- CFS
- There are a number of scheduling classes
  - An example would be:
    - Default - most processes are here
    - real time - important processes.
  - But more can be added.
  - The kernel can run a different scheduler on each class
  - Priorities are assigned to the classes
- CFS uses a targeted latency.
  - Within a given amount of time, every process should run a minimal amount.
  - One source lists this as 20 milliseconds.
  - On a base level if the time slice is 20ms, and there are 5 processs each should get 4ms to run every 20ms.
  - As more processes are added or removed, this time decreases or increases.
  - When the number of tasks grows, the targeted latency can be increased by the kernel.
- Each task has a virtual run time or a weighted accumulated time used by the process
  - For a nice level of 0, vruntime = runtime.
  - For a nice level > 0 , vruntime = (1+α) * runtime
  - For a nice level < 0 , vruntime = (1-α) * runtime
- Compare p1 and p2.
  - Assume equal nice values.
  - but p1 is cpu bound and p2 is not.
  - Just for argument, say the time allocated to each process is 6ms.
  - So p1 will use the full time allocated to it (6 ms)
  - And p2 will use (say 1/2) of the time. (3 ms)
  - After two "rounds"
  - p1: 10, p2: 6
- It is clear that p2 is not using nearly the processor time as p1, so it should be scheduled more frequently.
- To do this the scheduler selects the task with the lowest virtual run time.
- Red - black trees
  - A red-black tree is a binary tree
    - There is a root node.
    - A node may have 0,1 or two children
  - With the binary search property
    - All nodes in the left sub tree have a value lower than the root node, all nodes in the right sub-tree are larger.
  - With the red-black property
    - Nodes are red or black.
    - The root is black.
    - No red node may have a red parent
    - Every path from a node to the null nodes (leaves) have the same number of black notes.
    - All leaf notes are black.
  - Red black trees have the following properties
    - The height of the tree is approximately O(log₂ n)
    - Insertion and deletion is O(log₂ n)
  - I don't know red black trees, but sources say we can keep a pointer to the leftmost node, so extraction is O(1)
  - For CFS, the queue is a red black tree based on vruntime.
    - One source says that this is accurate to the ns
  - AN example:
    - Assume the following burst timesp1:1, p2:3, p3:4, and a "quantum: of 5.
```
P1:0 P2:0 P3:0     select 1 between (P1, P2, P3)->  P3:
P1:0 P2:0 P3:4     Select 1 between (P1, P2) -> P1
P1:1 P2:0 P3:4     Select 1 between (P2) -> P2
P1:1 P2:3 P3:4     Select 1 between (p1) -> P1
P1:2 P2:3 P3:4     Select 1 between (p1) -> P1
P1:3 P2:3 P3:4     Select 1 between (p1,p2) -> P1
P1:4 P2:3 P3:4     Select 1 between (p2) -> P2
P1:4 P2:6 P3:4     Select 1 between (p1, P4) -> P4
-----------------------------------------------------
Time 14 out of a 15 ms time 
         
```
    - Note that if it runs like this for a while, (say 10-15 rounds)
      - Let's assume that there was a P4 which was sleeping the entire time.
      - P4's vruntime would not have been increasing so P4 would now be eligible for scheduling alot.
      - To prevent this, processes in a sleeping state have their vruntime incremented as well.
  - As we said before, there are a number of queues and each can run a different scheduler.
    - So the realtime queue implements 100 different priorities
    - Plus regular tasks with nice -20 to 19 (which map to 100 - 139)
    - And does round robin / fifo / your choice at 0, then 1, ... then 99, then 100 then 101 ... 139
  - Linux does NUMA aware load balancing
    - Processes are kept
      - On the same core (L1 cache)
      - On the same CPU (L2 cache)
      - On the same CPU Collection (L3 cache)
      - See the picture on 238
  - EEVDF
    - Motivation:
      - There is no way to express latency requirements in the CFS scheduler.
      - IE Sometimes I NEED to get things done quickly, but the rest of the time it is not a problem.
      - IE I don't need more time, but when I need the time, I need it.
    - EEVFD has the same idea s CFS for dividing CPU time fairly
      - But it maintains a "lag" or the time a process did not get.
      - In our example: P1:4 P2:6 P3:4
        
        Each process should have had 5 ms
        So P1 and P3 have a lag of 1ms.
      - Processes are only eligible to run if they have a 0 or positive lag.
    - Another factor is a "virtual deadline"
      - The earliest time the process should have received its CPU time.
      - This is time slice/weight + eligible time
        
        Eligible time is vruntime
        I BELIEVE that weight is the priority.
        Or possible sum of priorities / process priority
      - The less of the time slice used
        
        the greater the lag. (more eligible)
        And the "earlier" the earliest time.
    - Processes are given a latency nice value, which gets factored into the virtual deadline.
      - So processes that need to respond to events are given an good priority.
      - and processes that just chug away are given a bad priority.
    - The scheduler will select among the eligible processes the one with the earliest virtual deadline.