[LITMUS^RT] Disk i/o

[ayoade gbadebo]

Thanks
On Feb 10, 2014 10:42 AM, "Glenn Elliott" <gelliott at cs.unc.edu> wrote:

>
> 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
> _______________________________________________
> litmus-dev mailing list
> litmus-dev at lists.litmus-rt.org
> https://lists.litmus-rt.org/listinfo/litmus-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20140210/95f4037a/attachment.html>