BFS: Brain F*ck SchedulerJacob Chan

Objectives

Brain F*ck Scheduling What it is How it works Features Scalability Limitations

Definition of Terms

Brain F*** Scheduler: What and Why?

I don’t curse FYI. It’s against my integrity So for the purpose of this class, let’s say that it’s BFS

Goals Minimize complex designs of CPU process schedulers

Implement a simpler design (because BFS is an alternative to Completely Fair Scheduler or CFS)

Achieve desktop interactivity without the heuristics Aka improving desktop performance

Who operates desktops? How does the user interact to the desktop?

Brain F*** Scheduler: What and Why?

Con Kolivas Australian anesthetist Wrote patches to improve desktop performance

Linux developers mainly focused on server development prior to BFS Thus, he devised the BFS

BFS allowed enhancements for lower-spec devices Single cores Low power machines (like phones) Reason: low overhead (due to dropping lower priority tasks; more on this later)

Jiffy

Duration of one tick of the timer system interrupt 1 jiffy = 1 tick of system clock

Not absolute Dependent on clock interval frequency of the HARDWARE Linux on Intel i386 has a jiffy of 4 milliseconds (too slow!)

How does BFS Work?

System time is updated by an interrupt that is periodically sent out by the CPU Think of system time as the computer’s body clock (to be simpler) CPU will stop what it is doing and runs the timer interrupt service routine (just to

update system time) Effects

Jiffy is added (one tick of system clock) Preemption

CPU resumes whatever it is doing (unless there is a preemption)

Key Feature: Virtual Deadline

Deadlines imposed on soft real-time system Not really a critical deadline (as in life-or-death) Service the earliest deadline as much as possible Expired deadlines are not BOOM! But if there are, finish it right away.

Virtual deadlines may be ignored(depending on priority of process), and can also be recomputed

In BFS, virtual deadlines are only used for normal and idle processes Including tasks at the same level Real time tasks go ahead of normal tasks!

BFS: Variables

rr_interval Round robin interval (can be found in /proc/sys/kernel/rr_interval) Default value: 6ms

Humans can detect jitter in approximately 7ms Higher than 6ms will result into worse latencies

Latency vs throughput: what are the difference? Time quantum is equal to this value Affects in computing virtual deadlines (more on this later)

iso_cpu Used for isochronous scheduling Default value: 70%

Setting this to 0 removes running pseudo-real-time tasks Setting this to 100 results into users getting round robin access (SCHED_RR)

BFS: Variables

Scheduling policies SCHED_ISO (Isochronous Scheduling)

Allows non-root users to run tasks with an almost real-time priority If isochronous task exceeds iso_cpu time, then it is demoted to a normal

task During this, total CPU power is computed

SCHED_IDLEPRIO (scheduling tasks that would run only if processor is idle)

Very low priority!

General Features of BFS

Only one runqueue for the ENTIRE SYSTEM, not each CPU This makes BFS unique from other schedulers (since other schedulers are on a per-

core basis) Maximum size = (# of tasks requesting CPU time) – (logical processors) + 1

O(n) worst case (what is n?)

Relies on virtual deadlines for normal (and idle, if any) priority tasks

Process accounting does not rely on sleep time

Computation of Virtual Deadline

Only applies to normal or idle tasks

When task requests CPU time, it enters the ready queue Priority ratio (based on nice level)

Nice level = 100% for -20, +10% for every level above that Virtual deadline = (current time in jiffies) + (priority ratio * rr_interval) Time slice = rr_interval

Computation of Virtual Deadline

Only applies to normal or idle tasks

When task requests CPU time, it enters the ready queue Priority ratio (based on nice level)

Nice level = 100% for -20, +10% for every level above that Virtual deadline = (current time in jiffies) + (priority ratio * rr_interval) Time slice = rr_interval

Computation of Virtual Deadline

When task uses up time slice, its time slice is refilled and its virtual deadline is recomputed then it is put back to the runqueue

The virtual deadline will remain unchanged if the task goes to sleep without using its allocated time slice

Why would a task go to sleep?

BFS: New Task Inserted

BFS runqueues have 103 priority queues Each is a double linked list implementation 100 for static real-time tasks 1 for isochronous 1 for normal 1 for idle

When task is inserted, a corresponding bit in a bitmap of priorities is updated Indicates that this task is waiting to be run

BFS: New Task Arrives

When task arrives (or ready to be in the runqueue) If there is an available processor, immediately assign the task to that processor (to

run it) Requires O(n), n = number of CPUs

Else, preempt the running task with the lowest priority, if the task’s priority and virtual deadline allows it (or latest deadline, if applicable)

Check priority, then virtual deadline (only for normal or idle tasks) If no available processor and preemption, then put the task in the appropriate

priority queue O(1)

BFS: Rescheduling

Tasks return to runqueue when: Time slice allocated is consumed. Time slice and virtual deadline are recomputed It goes to sleep or is preempted. Time slice and virtual deadline are not recomputed

Check bitmap to see priority level tasks Real-time -> isochronous -> normal -> idle

Each priority queue has its own algorithm to choose next process to run Real-time with same priority level tasks are in FIFO Isochronous tasks are in FIFO Among normal and idle tasks, earliest virtual deadline is chosen

Chosen process is removed from the runqueue and dispatched to the processor

BFS: Rescheduling

It’s not always the case that normal/idle queues use priority-oriented algorithms Normally, the earliest deadline task is chosen

But this takes O(n), with n = number of processes in queue If process with expired deadline is found while searching, then choose that process

immediately! Even if there is a task with an earlier and expired deadline along the list

BFS: Computer Affinity

Tasks can be assigned to any CPU, but idle processors are ranked according to affinity

Temporal locality tasks that have run at least once are assigned to the same processor (or processor in

the same cache)

Lab 6: Answering Questions

There will be no lab for this session (in order to prepare for next week’s midterms)

However, the following questions must be answered first (next slide)

No need to submit a certificate of authorship (since submission is notes-based)

This will count as a normal lab

I have uploaded BFS notes for this exercise (since some of them come from the notes)

Deadline: 11:55 pm tonight (it’s easy anyway)

Lab 6: Answering Questions

1. Why is there a subtraction of number of processors in computing for the maximum size of the runqueue? What about the +1? (2 pts)

2. Based on the niceness level, which has higher priority, a process with a niceness level of 8 or -5? Show your solution (2 pts)

3. Why does processing not account of sleep time? (2 pts)

4. If a process A will run on processor B located at cache C, why will it prefer to run in that same processor? (2 pts)

5. Describe subtick accounting in your own words (2 pts)