1) The document discusses Time-Sensitive Linux (TSL), which aims to support time-sensitive applications on commodity operating systems like Linux. 2) TSL improves kernel latency through an accurate timer mechanism called firm timers, a responsive kernel using lock-breaking preemption, and effective scheduling using proportion-based and priority-based algorithms. 3) Evaluation shows TSL reduces timer latency to under 1ms and preemption latency to under 1ms, improving synchronization of media playback under load compared to standard Linux.

1. Supporting Time-Sensitive
Applications on a Commodity OS
Ashvin Goel, Luca Abeni, Charles Krasic, Jim Snow
and Jonathan Walpole
Presenter : Namhyuk Ahn

2. Real-Time and Time-Sensitive Applications
§ Real-Time system
• Must meet an exact (or very nearly) deadline
• Failure to meet deadline means system failures
• e.g. space shuttle, air craft..
§ Time-sensitive applications
• Applications with real-time requirements
• e.g. media player
Distributed Shared Memory: Concepts and Systems 2

3. Motivation
§ Needs of time-sensitive application on commodity OS increase
§ However,
§ Most commodity OS aim to maximize system throughput
• These don’t consider real-time nor time-sensitive applications
§ Most real-time OS focus on hard real-time scenario
• System throughput is decreased and limited
§ Solution: General-purpose OS should offer both properties
• Time Sensitive Linux (TS-Linux)
Distributed Shared Memory: Concepts and Systems 3

4. Problems of Time-Sensitive Application
§ Time-sensitive applications require timely resources allocation
§ Minimize kernel latency is important issue
• Timer latency due to inaccurate timer
• Preemption latency due to threads executing in kernel cannot be preempted
• Scheduling latency is time taken to schedule the event
Distributed Shared Memory: Concepts and Systems 4

5. Solutions
§ TSL improves three keys causing latency
• Timer latency → Accurate timer mechanism
► Firm timer
• Preemption latency → Responsive kernel
► Lock-breaking preemptible kernel
• Scheduling latency → Effective scheduling
► Proportion-period scheduler
► Priority-based scheduler
§ TSL is version of Linux that can:
• Effectively run time-sensitive applications
• Effectively run throughput applications
• Be implemented without modifying existing applications
Distributed Shared Memory: Concepts and Systems 5

6. Timer Mechanism
§ Periodic timers
• Timer interrupts periodically; Max timer latency equals to the period
• Reducing latency increase interrupt overhead
§ One-shot timers
• Interrupts only when needs
• Cost of reprogramming
• High accuracy but high interrupt overhead
§ Example: Two task with periods 5, 7ms and run 35ms
• Periodic timers with period of 1ms
► Maximum latency is 1ms; 35 interrupts
• One-shot timer
► Relatively small latency; 11 interrupts (5ms, 7ms, 10ms, 14ms ..)
Distributed Shared Memory: Concepts and Systems 6

7. Timer Mechanism
§ Soft timers
• One-shot timer have interrupt overhead
• Reduce cost of context switch caused by interrupts
• But, timer latency is increase
§ Procedure
1. At some points, system will arrive at “trigger states”
o End of system call, exception handler or interrupt handler
o CPU idle
2. This invoke event handler; there is no overhead since already context-
switched
3. Soft timer checks for any pending events without hardware timer cost
Distributed Shared Memory: Concepts and Systems 7

8. Accurate Timer Mechanism – Firm timer
§ Firm timers
• Combine all the advantages of three timers before
• Overshoot parameter: bridge between one-shot and soft timer
• This makes unnecessary interrupts avoided
• High overshoot = soft; low = one-shot
Distributed Shared Memory: Concepts and Systems 8
Time
One-shot
timer expired
Overshoot
syscall
Programmed
One-shot interrupt
Dispatch and reprogram
one-shot timer
Interrupt does not occured
In case no syscall in overshot period, it perform as one-shot timer

9. Responsive Kernel
§ Kernel is responsive when non-preemptible section is small
§ The case scheduler is not able to run
• Interrupts is disabled (has to ready in ready-queue)
• Another thread is executing critical section in kernel
§ So, length of non-preemptible section is important
• But traditional commodity kernel disable preemption for the entire kernel
Distributed Shared Memory: Concepts and Systems 9

10. Fine-grained Preemptible Kernel
§ Explicit preemption
• Explicit insertion of preemption points inside the kernel
• Kernel explicitly yields CPU to scheduler when meet preemption point
• Has to be manually placed preemption points
§ Anytime preemption
• Allow preemption anytime kernel not manipulating shared data structure
• Shared kernel data must be protected using mutex or spinlock
• High latency when spinlock are held long time
Distributed Shared Memory: Concepts and Systems 10

11. Fine-grained Preemptible Kernel
§ Lock-breaking preemption
• Combine the above ideas
• TSL use lock-breaking preemption
• Split long spinlock section to multiple acquire-release points
Distributed Shared Memory: Concepts and Systems 11
acq()
... // manipulate shared data
rel()
… // preemptive kernel, check for expired scheduler
reacq()
…
rel()
acq()
…
rel()

12. Scheduling
§ Highest priority goes first
• Very simple
• But misbehaving and high-priority process can starve all other tasks
• Temporal protection issue:
► don’t make misbehaved task consuming too much execution time
Distributed Shared Memory: Concepts and Systems 12

13. Scheduling
§ Proportion-period scheduling
• Each task is allocated a fixed proportion
of CPU
• Provide temporal protection
• Q and T are adjustable by feedback
controller mechanism
• After executing for time Q, it block until
next T (or schedule for non-TS task)
13
T1
T2
2/3
1/3
Proportion Q
Proportion Q
Time
Period T

14. Scheduling
§ TSL combines proportion-based and fixed priority scheduler
• Fixed priority schedule doesn’t guarantee temporal protection
• Make proportion Q with respect to fixed priority
• Sounds good, but few exceptions
Distributed Shared Memory: Concepts and Systems 14

15. Scheduling
§ Exception case:
C1
Server
High priority
Low priority
Time
C1 scheduled Server
run
C2 Mid priority
Blocking call
C1 Ready to runC2
run
C2 preempts server
: Priority inversion for C1

16. Scheduling
§ Exception case:
C1
Server
High priority
Low priority
Time
C1 scheduled Server
run
C2 Mid priority
Blocking call
C1 Ready to run
Highest locking priority (HLP):
When a task acquires a resource, it gets the
highest priority that can acquire this resource
e.g. server task is now priority of C1

17. Evaluation
§ Setup:
• Modified version of Linux 2.4.16
• + Firm timer, lock-breaking and proportion-period scheduler
• 1.5 GHz Intel Pentium 4
• 512 MB RAM
Distributed Shared Memory: Concepts and Systems 17

18. Evaluation
§ Micro benchmarks
• Evaluate timer latency and preemption latency
• Measure time that process actually sleep in time-sensitive process using
nanosleep()
§ Timer latency
• Standard Linux: 10ms
• + firm timer: < 1ms
§ Preemption latency
• Evaluate when number of system loads are run in background
• Linux + firm timer: > 5ms
• + lock-break: < 1ms
Distributed Shared Memory: Concepts and Systems 18

19. Evaluation
§ Evaluation on real-world application
• Measure audio/video sync skew in Mplayer (media player)
§ Evaluate under three scenarios
1. Non-kernel CPU load
o User-level stress test is run in the background
2. Kernel CPU load
o Large memory buffer is copied to a file (user to kernel space)
3. File-system load
o Large directory is copied
Distributed Shared Memory: Concepts and Systems 19

20. Evaluation
§ Non-kernel CPU load
Distributed Shared Memory: Concepts and Systems 20

21. Evaluation
§ Kernel CPU load
Distributed Shared Memory: Concepts and Systems 21

22. Evaluation
§ File-system load
Distributed Shared Memory: Concepts and Systems 22

23. Evaluation
§ Preemption overhead
• Memory access (access 128MB array thus produce page fault)
► TSL overhead: 0.42% std 0.18%
• Fork (create 512 processes)
► TSL overhead: 0.53% std 0.06%
• File system (copy data from 2MB user buffer to 8MB file)
► TSL overhead: no significant overhead
Distributed Shared Memory: Concepts and Systems 23

24. Evaluation
§ Firm timer overhead
Distributed Shared Memory: Concepts and Systems 24

25. Conclusion
§ TSL provides real-time support for commodity OS by,
• Firm timer
• Responsive kernel
• Proportion-based scheduler
§ TSL can be used in both time-sensitive and throughput oriented app
Distributed Shared Memory: Concepts and Systems 25

26. Discussion topics
§ Rethinking the Real-time
• Requirements for RT system
► What are needed to ensure exact (or near-exact) timing?
• Example of time-sensitive applications have to run in commodity OS
• How to bring RT concept to commodity OS efficiently?
Distributed Shared Memory: Concepts and Systems 26

27. Discussion topics
§ What features should we consider to build Distributed RTOS?
Distributed Shared Memory: Concepts and Systems 27