bfs: brain f*ck scheduler jacob chan. objectives brain f*ck scheduling what it is how it works ...
TRANSCRIPT
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)