Formally verify Brain Fuck Scheduler via model checking using Uppaal with timed-automata and Uppaal favored Linear Temporal Logic.

1. Case Study: formal verification
of the Brain Fuck Scheduler
Abbr. BFS for short, and for reduced profanity in this talk
Presented by: Mengxuan Xia
McGill University

2. August 5th
2009

3. August 9th
2009
BUT YOU CAN TRY BFS!

4. Brain Fuck Scheduler (BFS)
• An alternative to the default Completely Fair Scheduler (CFS) of the
Linux kernel.
• Released by Con Kolivas on August 9th 2009
• Also known for his bitcoin mining software CGMiner

5. BFS: Pros and Cons
Pros
• Outperform CFS of the vanilla
kernel in almost all benchmarks
• (Back in 2009) You can compile a
C program while watching video
in full screen.
• Not doable with CFS, the video
will lag and sound goes out of sync
Cons
• Does not scale on processors
with more than 16 cores. (old
result)

6. How BFS and task scheduling works
(abstracted)
• Two types of tasks
• Realtime
• Quad copter reading data from
gyroscope and adjust motor speed.
Must happen in realtime! No need to
adjust motor speed when it already
crashed!
• Normal Photo by Doodybutch

7. BFS always runs realtime tasks first

8. How does BFS deal with realtime task?
O(1) scheduling, in a FIFO pipe.

9. How does BFS deal with normal task?
Using a virtual deadline mechanism.

10. Virtual deadline – how does it work?
• Each process is assigned with a virtual deadline.
• The virtual deadline is the time that they can wait in the queue.
• Virtual deadline determined proportional to NICE level.
• Deadline is virtual – nothing bad happens if deadline is passed.

11. How does BFS pick a normal task?
• If deadline of a process already passed, run it immediately.
• Otherwise find and run the process with the closest deadline.

12. It’s time to do verification

13. Related work in scheduler verification
• Lone Halkjaer, Karen Haervi, Anna Ingolfsdottir, Verification of the legOS
Scheduler using Uppaal, Electronic Notes in Theoretical Computer Science,
Volume 39, Issue 3, 2000, Pages 273-292.
• Xu Ke; Pettersson, P.; Sierszecki, K.; Angelov, C., "Verification of COMDES-II
Systems Using UPPAAL with Model Transformation," Embedded and Real-
Time Computing Systems and Applications, 2008. RTCSA '08. 14th IEEE
International Conference on , vol., no., pp.153,160, 25-27 Aug. 2008
• Penix, J.; Visser, W.; Engstrom Verification of time partitioning in the DEOS
scheduler kernel, E.; Larson, A.; Weininger, N., "," Software Engineering,
2000. Proceedings of the 2000 International Conference on , vol., no.,
pp.488,497, 2000 (This one uses SPIN)

14. Why does one want to verify BFS?
• BFS outperforms the default CFS in benchmark tests with such a
simple task selection strategy – does this performance gain comes
with a cost of undesirable side-effects?

15. What I hoped to verify
• Fairness of the scheduler
• Starvation-free

16. What I hoped to verifyied
• Fairness of the scheduler
• Starvation-free

17. Attempted to use Spin/Promela
• Did not work
• No notion of clock in Promela
• Had to implement a clock and synchronize it with the rest
• Counter-intuitive
• Brain-F#!ked

18. UPPAAL
• Developed by Uppsala University,
Sweden and Aalborg University in
Denmark.
• A timed-automata verifier
• With a horrible UI
• Draw timed-automata
• Write declarations of the symbols
used in the system
• Run it in the simulator
• Verify the (UPPAAL flavored) LTLs

19. BFS automata

20. Process/task
automata

21. Suppose we have these processes (all non-realtime
tasks)
• Process 0: nice level -1, deadline is current tick + 5 ticks
• Process 1: nice level 0, deadline is current tick + 10 ticks
• Process 2: nice level 1, deadline is current tick + 40 ticks
• Process 3: nice level 0, deadline is current tick + 10 ticks

22. Verification – All satisfied
• Starvation-free
• For all p in processes: infinitely often p in Added state implies that infinitely
often p in running state
• Timeout guarantee (a process cannot run infinitely)
• For all p in processes: p in running state implies eventually p in added state
• Took over 2 hours to run.

23. UPPAAL can give us even more
information
sup: wait[0] <-> “The least upper bound on process 0’s wait time”

24. Recall our processes
• Process 0: nice level -1, deadline is current tick + 5 ticks
• Process 1: nice level 0, deadline is current tick + 10 ticks
• Process 2: nice level 1, deadline is current tick + 40 ticks
• Process 3: nice level 0, deadline is current tick + 10 ticks

25. What’s the maximum time they will stay
waiting in the run queue?
sup: wait[0],wait[1],wait[2],wait[3]
Verifying formula 11: sup: wait[0],wait[1],wait[2],wait[3]
-- Formula is satisfied.
sup{true}:
wait[0] <= 16
wait[1] <= 20
wait[2] <= 51
wait[3] <= 20

26. BFS is verifiably starvation-free
for our set of normal tasks

27. What about realtime tasks?
• As soon as you add a realtime task to the system, starvation-free
property gets violated
• See for yourself:
Evil Realtime Process:
while (true) {
// I’m going to starve everyone else
}

28. But that’s fine
• Only kernel code or root user can run realtime process
• Normal desktop users are not affected
• This explains why bad drivers can freeze your system. Recall the
spinlock example that Syed gave yesterday.

29. What to watch out for when modeling a
timed automata system
• Don’t attempt to use an integer counter. It will cause exponential
state space blow up. That’s not how time automata work.
• Instead, try to solve counting problem by using multiple clocks and
taking their difference.
• Subtracting/adding integers to clock values make the system
undecidable! Find other alternative approaches.
• Counter-intuitive at first.
Still counter-intuitive weeks later.

30. Why I could not verify fairness?
• A system is fair if every process of the same nice level get to run for
exactly the same cumulative duration
• How does one write an LTL formula for that?

31. Conclusion
• BFS is verifiably starvation-free for our set of normal tasks
• Realtime tasks break starvation-free property
• Easy to modify this UPPAAL diagram to work with any set of tasks
• Theoretically possible to enumerate all sets of tasks and verify all
these finite sets of tasks.
• there can be at most 2^16 processes (on Linux), each with nice value from -20
to 19)

32. Future work
• Fix the horrible UPPAAL tool.
• Extend this model for multi-core system. [1]
• Find a way to verify (not necessarily deterministic) fairness. With
Statistical Model Checking perhaps? [2]
• Model processes preemption
[1] Jan Madsen Aske Brekling, Michael R Hansen. Models and formal verification of multiprocessor system-on-chips.
The journal of Logic and Algebraic Programming, 77(1):1–19, 2008.
[2] Gerd Behrmann, Kim G. Larsen, and Jacob I. Rasmussen. 2004. Priced timed automata: algorithms and
applications. In Proceedings of the Third international conference on Formal Methods for Components and
Objects (FMCO'04), Frank S. Boer, Marcello M. Bonsangue, Susanne Graf, and Willem-Paul Roever (Eds.).
Springer-Verlag, Berlin, Heidelberg, 162-182.

33. BFS UPPAAL automata available on Github
https://github.com/xiamx/bfsverification
Question?