Real-Time Operating Systems Issues Example of a real-time capable - PDF document

CPSC-663: Real-Time Systems Real-Time Scheduling in Solaris Real-Time Operating Systems Issues • Example of a real-time capable OS: Solaris. S. Khanna, M. Sebree, J.Zolnowsky. “Realtime Scheduling in SunOS 5.0”. USENIX - Winter ‘92. • Problems with the design of general-purpose real-time capable OS: Solaris J.Nieh, J.G.Hanko, J.D. Northcutt, G.A.Wall. “SVR4 UNIX Scheduler Unacceptable for Multimedia Applications.” NOSSDAV ‘93. URL: http://www.cs.columbia.edu/~nieh/#publications Realtime Scheduling in SunOS 5.0 • Requirements for Solaris as a real-time OS: – Scheduling of tasks in kernel should be deterministic. Kernel should be free from unbounded priority inversion. – Allow for mixed-mode applications: real-time and non-real-time components. – Appropriate for multiprocessor machines. – Provide standard interface to user, such as System V. • Historically: unbounded dispatch latency caused by non-preemptible kernel . – Solution 1: Well-defined preemption points. (?) – Solution 2: Fully synchronize access by kernel code to kernel data structures. • Reduces set of non-preemptible portions in kernel. • Kernel is multithreaded. 1

CPSC-663: Real-Time Systems Real-Time Scheduling in Solaris Scheduling Classes • Time-Sharing class: – round robin scheduling. • Sys class: – fixed priority scheduling, – not accessible by the user. • Real-Time class: – fixed priority scheduling. interrupt 159 59 • priocntl (2) – Change scheduling class or other RT scheduling parameters. RT 99 0 sys +20 59 TS TS 0 -20 Scheduling • State of thread: blocked, runnable, executing • Scheduling operations (operations on dispatch queue) are protected by single RT0 RT1 RT2 spin lock schedlock . runnable threads • Variables per processor: cpu_thread : thread curr. executing dispatch queue – cpu_dispthread : thread last sched. – for disp cpu_idle : special idle thread – S0 BT0 BT1 BT2 cpu_runrun : user-level preemption – cpu_kprunrun : kernel-level preemption blocked threads – cpu_chosenlevel : next trhead to DT – preempt executing thread P1 processor 2

CPSC-663: Real-Time Systems Real-Time Scheduling in Solaris Operations on Dispatch Queues put thread in dispatch queue • setfrontdq() (when thread is preempted) • setbackdq() find CPU on which runnable thread might • cpu_choose() be dispatched give up CPU when priority is lowered • cpu_surrender() select a thread for execution from the • disp() dispatch queue (used by swtch) select highest-priority thread for execution • swtch() if none is found, returns idle thread modifies many per-processor variables attempt to preempt kernel • kpreempt() kpreempt_disable() disable preemption for critical interval • kpreempt_enable() reenable preemption • Priority Inversion • Priority inversion happens due to – non-preemptable portions – access to synchronization objects – “hidden scheduling” • Synchronization Objects (mutex, r/w locks) – Solution: basic priority-inheritance protocol • Hidden Scheduling – Work done asynchronously in kernel on behalf of threads without regard to their priority. process – Example: streams processing user kernel check pending streams requests – Example: timeouts done at lowest interrupt level – Solution: Move this code into kernel threads running at sys priority level. 3

CPSC-663: Real-Time Systems Real-Time Scheduling in Solaris Priority Inheritance • Primitives: impose priority of argument thread onto all – pi_willto(thread) threads that block it, directly or indirectly release priority inheritance – pi_waive() • The function pi_willto() is called after the thread has been put to sleep in the queue associated with the synchronization object. The information about the synchronization object can therefore be recovered. • Priority inheritance for readers/writers locks: – when writer owns the lock: no problem – when readers own the lock: • potentially many “owners”; not practical to keep pointer from resource to every thread that owns it • Solution: define a single “owner-of-record”, which is only thread that inherits priority. Applicability of SunOS 5.0 for Multimedia Applications J.Nieh, J.G.Hanko, J.D. Northcutt, G.A.Wall. “SVR4 UNIX Scheduler Unacceptable for Multimedia Applications.” NOSSDAV ‘93. URL: http://www.cs.columbia.edu/~nieh/#publications • Objectives of real-time OS for general-purpose workstations – Provide real-time guarantees without reducing general capabilities of workstations – Manage resources so that other applications can operate correctly. – SunOS 5.0 (SVR4) provides real-time static-priority scheduler. • Question: How well are resources managed? 4

CPSC-663: Real-Time Systems Real-Time Scheduling in Solaris Experimental Evaluation: Overview • Platform – Sun Sparc10 – Solaris 2.2 – Scheduling classes (RT class, TS class, SYS class) • Experiment (measurement) criteria: – Interactive: • minimize average and variance between user input and response • Typing, cursor motion, mouse selection <= 50 - 150 ms. – Continuous media: • Minimize difference between average display rate and desired display rate. • Minimize variance of display rate. – Batch: • “Minimize difference between actual time of completion and minimum time of completion when whole machine is dedicated.” Experiment: Workload • 3 classes of workload • Interactive: (editors, GUIs) – TYPING: Emulate a user typing, and display characters on the screen. • Continuous media: (television, teleconference) – VIDEO: Capture data from digitizer board and display through x- windows server. • Batch: (compilations, scientific computation) – make: Repeatedly fork and wait for small processes to complete. • Instrumentation of application and system software components does not measurably change the performance. 5

CPSC-663: Real-Time Systems Real-Time Scheduling in Solaris Experiment: The Baseline Application Measurement Mean Std. Dev. Typing Latency between character arrival 38.5 ms 15.7 ms and rendering to frame buffer Video Time between display of successive 112 ms 9.75 ms frames Compute Time to execute one loop iteration 149 ms 6.79 ms Table: Application Baseline Values • What is a well-behaved system? – Concurrent applications should make some progress – No case where system fails to respond to operator input – User should exercise wide range of influence over system behavior. Experiment 1: Run all tasks in RT class • Window system is no longer accepting input events from mouse or keyboard. • Command interpreter not permitted to run. • System blocked by batch-job – Identified as I/O intensive interactive job. Gets priority boosts for sleeping. • Window server develops backlog of service requests. As it works down its queue, it gets identified as compute bound. • Table entries are relative to baseline (tall is better) • T: TYPING character latency • V: time between display of successive frames for VIDEO. • C: time for one iteration in COMPUTE. 6

CPSC-663: Real-Time Systems Real-Time Scheduling in Solaris What can the System Administrator do? Increase priority of X- Server, decrease priority of batch task In addition, decrease priority of VIDEO a bit Decrease priority of VIDEO a little bit more. Play with RT Class 7

CPSC-663: Real-Time Systems Real-Time Scheduling in Solaris Result: New TS Class • Removes anomalies of identifying batch jobs as interactive and vice versa. • Ensures that each process makes steady progress. • Reduces feedback interval • Included in Solaris 2.3. 8