1. BFS: Brain F*ck Scheduler Jacob Chan

2. Objectives  Brain F*ck Scheduling  What it is  How it works  Features  Scalability  Limitations  Definition of Terms

3. 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?

4. 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)

5. 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!)

6. 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)

7. 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!

8. 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 )

9. 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!

10. 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

11. 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

12. 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

13. 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?

14. 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

15. 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)

16. 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

17. 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

18. 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)

19. 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)

20. 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)