[LITMUS^RT] Disk i/o

[Glenn Elliott]

On Feb 10, 2014, at 7:40 AM, ayoade gbadebo <gbaduz at gmail.com> wrote:

> Does litmus scheduler plugins factor in disk i/o operations like file reads which may cause the litmus rt  task to block while reading data from disk?
> I observed that the litmus  task do block when I include a file read from disk in the task. I want to confirm if my observation is right?

Hi Ayoade,

Litmus allows tasks to self-suspend for any reason, including disk I/O.  The limitation with I/O is that Litmus has not been extended to implement real-time I/O.  Under Litmus, I/O operations from real-time and non-real-time tasks are not distinguished—the real-time operation has no priority over the non-real-time one.  Low-priority work can also prevent high-priority work from being unblocked.  Long story short, it is hard to ensure real-time priority; priority inversions are not guaranteed to be bounded.

Consider the following scenario:
1) Time T1: The highest priority (HP) real-time task issues an I/O operation and suspends.  The I/O operation is considered completed when an interrupt bottom-half wakes up the HP task.
2) Time T2: Low-priority real-time tasks are scheduled.
3) Time T3: The I/O device raises an interrupt to signal completion.  The interrupt top-half is handled immediately, but the interrupt bottom-half is queued for execution in a worker thread (e.g., Linux’s non-real-time ksoftirqd thread).
4) Time T4: Low-priority real-time tasks complete.
5) Time T5: The interrupt bottom half from time T3 executes on an idle processor.  The HP task is awoken.
6) Time T6: The HP task resumes execution.

Without any real-time scheduling, the duration between time T3 and T5 is UNBOUNDED.  Thus, real-time guarantees cannot be made.

Does the above scenario hold for disk I/O?  I am certain that NFS file systems will suffer from unbounded priority inversions because of its reliance on the network.   However, I am not familiar with Linux’s block I/O schedulers and disk I/O drivers—you may or may not run into problems with them.  If the disk driver does all its work in the interrupt top-half, then you’ll be safe (since top halves always execute with maximum priority).  However, you can suffer from unbounded priority inversions if the disk driver uses interrupt bottom halves (i.e., Linux tasklets and work queue items), or other driver-specific helper demon threads.  You’ll need to do some investigation to know for sure.

Further reading:
* “The Limitation of Fixed-Priority Interrupt handling in PREEMPT_RT and Alternative Approaches”  (shameless self-promotion): http://www.cs.unc.edu/~anderson/papers/rtlws12.pdf
* “Process Aware Interrupt Scheduling and Accounting”: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4032348
* "Modeling Device Driver Effects in Real-Time Schedulability Analysis: Study of a Network Driver”: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4155310
* “Schedulable Device Drivers: Implementation and Experimental Results”: http://retis.sssup.it/~faggioli/papers/OSPERT-2010-dlinterrupt.pdf   *** You’ll certainly want to read this one; it appears to deal with real-time disk I/O.

-Glenn