BFS: Brain F* ck Scheduler

BFS: Brain F*ck Scheduler Jacob 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_cputime, 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 • 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 • Why is there a subtraction of number of processors in computing for the maximum size of the runqueue? What about the +1? (2 pts) • Based on the niceness level, which has higher priority, a process with a niceness level of 8 or -5? Show your solution (2 pts) • Why does processing not account of sleep time? (2 pts) • 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) • Describe subtick accounting in your own words (2 pts)

BFS: Brain F* ck Scheduler