Introduction Process-aware Interrupt Scheduling and � While many RT operating systems exist, aim of this work is Accounting to empower off-the-shelf systems with predictable service management � Leverage widely-deployed systems having low development and maintenance costs � Add safe, predictable and efficient app-specific services Yuting Zhang and Richard West to commodity OSes for real-time use Boston University Boston, MA � Focus of this talk specifically on improving predictability {danazh,richwest}@cs.bu.edu and accountability of interrupt processing Computer Science Commodity OSes for Real-Time The Problem of Interrupts � Many variants based on systems such as Linux: � Asynchronous events e.g., from hardware completing I/O requests and timer interrupts… � Linux/RK, QLinux, RED-Linux, RTAI, KURT Linux, and � Affect process/thread scheduling decisions RT Linux � Typically invoke interrupt handlers at priorities above those of � e.g., RTLinux Free provides predictable execution of processes/threads kernel-level real-time tasks � i.e., interrupt scheduling disparate from process/thread � Bounds are enforced on interrupt processing scheduling overheads by deferring non-RT tasks when RT tasks � Time spent handling interrupts impacts the timeliness of RT tasks and require service their ability to meet deadlines � NOTE: Many commodity systems suffer � Overhead of handling an interrupt is charged to the process that is unpredictability (unbounded delays) due to interrupt- running when the interrupt occurs disabling, e.g., in critical sections of poorly-written � Not necessarily the process associated (if any) with the interrupt device drivers Goals Interrupt Handling � How to properly account for interrupt processing and � Interrupt service routines are often split into “top” and correctly charge CPU time overheads to correct process, “bottom” halves where possible � Idea is to avoid lengthy periods of time in “interrupt context” � How to schedule deferrable interrupt handling so that � Top half executed at time of interrupt but bottom half may predictable task execution is guaranteed be deferred (e.g., to a schedulable thread) �
Example: Linux Process-Independent Interrupt Service � Avoid undue impact of interrupt handling on CPU time for a � Traditional approach: Processes � I/O service request via kernel running process 1 � OS sends request to device 2 via driver code; � Execute a finite # of pending deferrable fns after top half P 1 P 2 P 3 P 4 � Hardware device responds w/ execution (in “interrupt context”) an interrupt, handled by a � Linux deferrable fns: softirqs and tasklets (bottom 1 4 “top half” halves now deprecated) � Deferrable “bottom half” 3 Interrupt handler � Iterate through softirq handling a fixed number of times completes service for prior Bottom Halves to avoid undue delay to processes but good interrupt and wakes waiting responsiveness for interrupts (e.g., via network) 3 process(es) – Usually runs w/ Top Halves interrupts enabled OS 4 � A woken process can then be � Defer subsequent bottom halves to threads interrupts 2 scheduled to resume after � Awaken “ksoftirqd_CPUn” kernel thread Hardware blocking I/O request Linux Problems Process-Aware Interrupt Handling � A real-time or high-priority blocked process waiting on I/O � Not all interrupts associated with specific processes may be unduly delayed by a deferred bottom half � e.g., timer interrupt to update system clock tick, IPIs… � Mismatch between bottom half priority and process � Not necessarily a problem if we can account for such � Interrupt handling takes place in context of an arbitrary costs in execution time of tasks e.g., during scheduling process � May lead to incorrect CPU time accounting � I/O requests via syscalls (e.g., read/write) associate a process with a device that may generate an interrupt � Why not schedule bottom halves in accordance with � For this class of interrupts we assign process priorities to priorities of processes affected by their execution? bottom half (deferrable) interrupt handling � For fairness and predictability: charge CPU time of interrupt � Allow top halves to run with immediate effect but consider handling to affected process(es), where possible dependency between bottom halves and processes Bottom Half Scheduling / Accounting Interrupt Accounting Algorithm � � Measure the average execution time of a bottom half (BH) Modify Linux kernel to include interrupt accounting Interrupt handler across multiple BH executions � TSC measurements on bottom halves BH accounter � On x86 use rdtsc since time granularity typically < 1 clock � Determine target process for interrupt Bottom Halves tick processing and update system time � Measure total interrupts processed and # processed for accordingly BH scheduler OS each process in 1 clock tick Top Halves � BH/interrupt scheduler immediately � Adjust system CPU time for processes due to mischarged between do_irq() and do_softirq() interrupt costs � Predict target process associated with interrupt and set BH priority � For simplicity, focus on interrupts for one device type (e.g., accordingly NIC) but idea applies to all I/O devices �
System CPU Time Compensation (1/2) System CPU Time Compensation (2/2) � N(t) - integer # interrupts whose total BH execution time = 1 � At each clock tick (do_timer) update accounting info as clock tick (or jiffy ) follows: � Actually use an Exponentially-Weighted Moving Avg for N(t), N’(t) x i (t) = x i (t) – m(t); // current # under-charged if +ve � N’(t) = (1- γ )N’(t-1) + γ N(t) | 0 < γ < 1 sign = sign of (x i (t)); while (abs(x i (t)) >= N(t)) // update integer # of jiffies � m(t) - # interrupts processed in last clock tick � system_time(P i ) += 1*sign; � x k (t) - # unaccounted interrupts for process P k � timeslice(P i ) -= 1*sign; � x i (t) = x i (t) – N(t); � Let P i (t) be active at time t m(t) = 0; � m(t) – x i (t) (if +ve) is # interrupts overcharged to P i Example: System CPU Time Compensation Interrupt Scheduling Algorithm � (1) Find candidates associated with interrupt on device, D � In top half can determine D P1 P2 P3 P4 P2 P1 P3 � A blocked process waiting on D may be associated with the interrupt 0 P1 1 2 3 4 5 6 7 8 t P1 � We require I/O requests to register process ID and I 1 I 2 I 1 I 3 I 2 I 3 I 1 I 1 I 4 I 3 I 2 I 1 I 1 I 4 I 3 I 3 I 2 I 1 I 1 I 3 priorities with corresponding device x 1 (1): -3 + 2 = -1, x 2 (2): -1 + 1= 0, � (2) Predicting process associated with interrupt on D x 3 (3): -2 + 2 = 0, x 4 (4) : -3 + 1 =-2, � At end of top half select highest priority ( ρ max(D) ) from x 4 (5): -2 + -4+ 0= -6, x 2 (6): 0 + -2 + 2 = 0, x 1 (7): -1 + -2+ 4= 1, x 3 (8): 0 + -3 + 4 = 1, processes waiting on D � Use a heap structure for waiting processes � (3) Compare priority of BH with running process � If ( ρ max(D) = ρ BH ) > ρ current run BH else process Interrupt Scheduling Observations Example: Interrupt Scheduling (1/3) � No need for ksoftirqd_CPUn � t 1 : P 1 issues I/O request and blocks, allowing P 2 to run � Run interrupt scheduler at time of process scheduling � t 2 : top half interrupt processing for P 1 in P 2 ’s context � If pending BH highest prio run in context of current � t 3 : top half completes process, else do switch to highest prio process � t 4 -t 5 : bottom half runs � t 6 : P 1 wakes up and runs � Setting prio of BH ( ρ BH ) to highest process prio ( ρ max(D) ) for ���������������� device D � Rationale: no worse than current approach of always t 1 t 5 t 6 preferring BH (at least for finite occurrences) over P 1 P 2 P 1 Process process � Simple priority scheme can provide better predictability Interrupt Handler It 1 IB 1 for more important processes Hardware t 2 t 3 t 4 �
Recommend
More recommend
