proposed FAQ entry for rt.wiki.kernel.org
Today, for the Nth time, I was asked by a potential customer "How does the RT patch improve latency?". I looked at rt.wiki.kernel.org, hoping (vainly) that someone had written up an elevator-pitch for the RT patch, but it was not to be. So I wrote up something that I hope made sense and sent it off.
Since then I did a little bit of tweaking and expansion and thought I'd send it to the RT users list to see if we can agree on an answer, then put that in the RT FAQ.
So, please read and critique the following:
Q. How does the Linux RT kernel improve "latency"?
A. The Linux RT patch modifies the behavior of spinlocks and interrupt handling, to increase the number of points where a preemption or reschedule may occur. This reduces the amount of time a high priority task must wait to be scheduled when it becomes ready to run, reducing event service time (or "latency").
Most spinlocks in the kernel are converted to a construct called an rtmutex, which has the property of *not* disabling interrupts while the lock is held and will sleep rather than spin. This means that interrupts will occur while rtmutexes are held and interrupt handling is a potential preemption point; on return from handling an interrupt, a scheduler check is made as to whether a higher priority thread needs to run.
The rtmutex locking construct also has a property known as "priority inheritance", which is a mechanism for avoiding a deadlock situation known as "priority inversion". In order to prevent a low priority thread that is holding a lock from preventing a higher priority thread from running, the low priority thread temporarily inherits the priority of the highest priority thread that is requesting the lock, which allows the low-priority thread to run until it completes its critical section and releases the lock.
In addition to changing spinlocks, interrupts have been threaded, meaning that instead of handling interrupts in a special "interrupt context", each IRQ has a dedicated thread for running its ISRs. Interrupts go to a common handler and the handler schedules the appropriate thread to handle the interrupt. This means that sleeping spinlocks (rtmutexes) have a context to return to and that interrupt handling can be prioritized by assigning appropriate realtime priorities to the interrupt threads.
Quoted 5 lines · Clark Williams
Today, for the Nth time, I was asked by a potential customer "How does the RT patch improve latency?". I looked at rt.wiki.kernel.org, hoping (vainly) that someone had written up an elevator-pitch for the RT patch, but it was not to be. So I wrote up something that I hope made sense and sent it off.
I have "elevator pitch" on my todo list as well. Good timing.
Quoted 8 lines
Since then I did a little bit of tweaking and expansion and thought I'd send it to the RT users list to see if we can agree on an answer, then put that in the RT FAQ.
So, please read and critique the following:
Q. How does the Linux RT kernel improve "latency"?
"Linux RT" ... pretty close to RTLinux, which of course we can't use, so maybe use "Real-Time Linux" or "The PREEMPT_RT patch".
Quoted 15 lines
A. The Linux RT patch modifies the behavior of spinlocks and interrupt handling, to increase the number of points where a preemption or reschedule may occur. This reduces the amount of time a high priority task must wait to be scheduled when it becomes ready to run, reducing event service time (or "latency").
Most spinlocks in the kernel are converted to a construct called an rtmutex, which has the property of *not* disabling interrupts while the lock is held and will sleep rather than spin. This means that interrupts will occur while rtmutexes are held and interrupt handling is a potential preemption point; on return from handling an interrupt, a scheduler check is made as to whether a higher priority thread needs to run.
Quoted 3 lines
The rtmutex locking construct also has a property known as "priority inheritance", which is a mechanism for avoiding a deadlock situation known as "priority inversion".
A reference might be a good idea. The medium priority tasks not interested in the contended resource is a key aspect of priority inversion.
http://en.wikipedia.org/wiki/Priority_inversion
Quoted 7 lines
In order to prevent a low priority
thread that is holding a lock from preventing a higher priority thread from running, the low priority thread temporarily inherits the priority of the highest priority thread that is requesting the lock, which allows the low-priority thread to run until it completes its critical section and releases the lock.
Quoted 8 lines
In addition to changing spinlocks, interrupts have been threaded, meaning that instead of handling interrupts in a special "interrupt context", each IRQ has a dedicated thread for running its ISRs. Interrupts go to a common handler and the handler schedules the appropriate thread to handle the interrupt. This means that sleeping spinlocks (rtmutexes) have a context to return to and that interrupt handling can be prioritized by assigning appropriate realtime priorities to the interrupt threads.
I think I'd focus a bit more on interrupt threads having configurable priorities.
I'm not sure the bit about "spinlocks have a context to return to" makes sense in an elevator-type pitch, might be too low level, and detract from the high-level message?
Signature · 3 lines
Darren Hart IBM Linux Technology Center Real-Time Linux Team
Quoted 14 lines · On Thu, 22 Oct 2009 11:16:27 -0700 Darren Hart <[email protected]> wrote:
Quoted 5 lines · Clark Williams
Today, for the Nth time, I was asked by a potential customer "How does the RT patch improve latency?". I looked at rt.wiki.kernel.org, hoping (vainly) that someone had written up an elevator-pitch for the RT patch, but it was not to be. So I wrote up something that I hope made sense and sent it off.
I have "elevator pitch" on my todo list as well. Good timing.
Quoted 5 lines
Since then I did a little bit of tweaking and expansion and thought I'd send it to the RT users list to see if we can agree on an answer, then put that in the RT FAQ.
Quoted 6 lines
Quoted 3 lines
So, please read and critique the following:
Q. How does the Linux RT kernel improve "latency"?
"Linux RT" ... pretty close to RTLinux, which of course we can't use, so maybe use "Real-Time Linux" or "The
PREEMPT_RTpatch".
How's this:
Q. How does Real-Time Linux (aka the PREEMPT_RT patch) improve "latency"?
Quoted 16 lines
Quoted 16 lines
A. The Linux RT patch modifies the behavior of spinlocks and interrupt handling, to increase the number of points where a preemption or reschedule may occur. This reduces the amount of time a high priority task must wait to be scheduled when it becomes ready to run, reducing event service time (or "latency").
Most spinlocks in the kernel are converted to a construct called an rtmutex, which has the property of *not* disabling interrupts while the lock is held and will sleep rather than spin. This means that interrupts will occur while rtmutexes are held and interrupt handling is a potential preemption point; on return from handling an interrupt, a scheduler check is made as to whether a higher priority thread needs to run.
Quoted 8 lines
Quoted 3 lines
The rtmutex locking construct also has a property known as "priority inheritance", which is a mechanism for avoiding a deadlock situation known as "priority inversion".
A reference might be a good idea. The medium priority tasks not interested in the contended resource is a key aspect of priority inversion.
Yeah, I didn't want to get into a full-on discussion of priority inversion, so a reference is a good idea.
Quoted 17 lines
Quoted 8 lines
In order to prevent a low priority
thread that is holding a lock from preventing a higher priority thread from running, the low priority thread temporarily inherits the priority of the highest priority thread that is requesting the lock, which allows the low-priority thread to run until it completes its critical section and releases the lock.Quoted 8 lines
In addition to changing spinlocks, interrupts have been threaded, meaning that instead of handling interrupts in a special "interrupt context", each IRQ has a dedicated thread for running its ISRs. Interrupts go to a common handler and the handler schedules the appropriate thread to handle the interrupt. This means that sleeping spinlocks (rtmutexes) have a context to return to and that interrupt handling can be prioritized by assigning appropriate realtime priorities to the interrupt threads.
Quoted 7 lines
I think I'd focus a bit more on interrupt threads having configurable priorities.
I'm not sure the bit about "spinlocks have a context to return to" makes sense in an elevator-type pitch, might be too low level, and detract from the high-level message?
Well, some of the people that have asked were actually looking for a more technical description than was available in, ahem, Marketing Literature. So I guess I was attempting to straddle that fence. I will re-arrange that last sentence to put prioritization first or may be split it into two sections. How about this:
This means that interrupt service order may be prioritized by assigning appropriate realtime priorities to the interrupt threads.
Yeah, I see what you mean about "context to return to". A bit too deep for the 30-second description.
Clark
Quoted 4 lines · Clark Williams
How's this:
Q. How does Real-Time Linux (aka the
PREEMPT_RTpatch) improve "latency"?
Works for me
Quoted 11 lines
Quoted 2 lines
I'm not sure the bit about "spinlocks have a context to return to" makes sense in an elevator-type pitch, might be too low level, and detract from the high-level message?
Well, some of the people that have asked were actually looking for a more technical description than was available in, ahem, Marketing Literature. So I guess I was attempting to straddle that fence. I will re-arrange that last sentence to put prioritization first or may be split it into two sections. How about this:
This means that interrupt service order may be prioritized by assigning appropriate realtime priorities to the interrupt threads.
I was specifically thinking that the balance between application and interrupt thread should be mentioned, while this seems to focus on the relative priorities of just the interrupt threads.
Signature · 3 lines
Darren Hart IBM Linux Technology Center Real-Time Linux Team
Quoted 7 lines · Clark Williams
So, please read and critique the following:
Q. How does the Linux RT kernel improve "latency"?
A. The Linux RT patch modifies the behavior of
spinlocks and
simpler: "Kernel-level locking". Avoids "whats a spinlock?"
Quoted 8 lines
interrupt handling, to increase the number of points where a preemption or reschedule may occur. This reduces the amount of time a high priority task must wait to be scheduled when it becomes ready to run, reducing event service time (or "latency").
Most spinlocks in the kernel are converted to a construct called an rtmutex, which has the property of *not* disabling interrupts while the lock is held and will sleep rather than spin.
Technically, not all spinlocks disable irqs.
maybe "property of *not* preventing task switching or suppressing interrupt services on a particular CPU while..."
Quoted 15 lines
This means that
interrupts will occur while rtmutexes are held and interrupt handling is a potential preemption point; on return from handling an interrupt, a scheduler check is made as to whether a higher priority thread needs to run.The rtmutex locking construct also has a property known as "priority inheritance", which is a mechanism for avoiding a deadlock situation known as "priority inversion". In order to prevent a low priority thread that is holding a lock from preventing a higher priority thread from running, the low priority thread temporarily inherits the priority of the highest priority thread that is requesting the lock, which allows the low-priority thread to run until it completes its critical section and releases the lock.
Quoted 8 lines
In addition to changing spinlocks, interrupts have been threaded, meaning that instead of handling interrupts in a special "interrupt context", each IRQ has a dedicated thread for running its ISRs. Interrupts go to a common handler and the handler schedules the appropriate thread to handle the interrupt. This means that sleeping spinlocks (rtmutexes) have a context to return to and that interrupt handling can be prioritized by assigning appropriate realtime priorities to the interrupt threads.
Further, user-level processes may be prioritized above device-level services, allowing computational load and I/O load to be dynamically expedited, partitioned, or decoupled.
Quoted 10 lines · On Thu, 22 Oct 2009 11:18:23 -0700 Sven-Thorsten Dietrich…
Quoted 7 lines · Clark Williams
So, please read and critique the following:
Q. How does the Linux RT kernel improve "latency"?
A. The Linux RT patch modifies the behavior of
spinlocks and
simpler: "Kernel-level locking". Avoids "whats a spinlock?"
Yeah, I can go with that. Although, we might do it this way:
The Linux RT patch modifies the behavior of the most common kernel-level locking primitive (the spinlock) and interrupt handling, to increase the number of points where a preemption or reschedule may occur.
Quoted 6 lines
Quoted 6 lines
interrupt handling, to increase the number of points where a preemption or reschedule may occur. This reduces the amount of time a high priority task must wait to be scheduled when it becomes ready to run, reducing event service time (or "latency").
Quoted 9 lines
Quoted 3 lines
Most spinlocks in the kernel are converted to a construct called an rtmutex, which has the property of *not* disabling interrupts while the lock is held and will sleep rather than spin.
Technically, not all spinlocks disable irqs.
maybe "property of *not* preventing task switching or suppressing interrupt services on a particular CPU while..."
Agreed, but the rtmutex *does* have the property of not disabling interrupts, so it's a nop when replacing spinlocks that don't as well. I do like calling out that the conversion explicitly enable task switching though. How about this:
Most spinlocks in the kernel are converted to a construct called an rtmutex, which has the property of *not* disabling interrupts or preventing task switching while the lock is held. It also has the property of sleeping on contention rather than spinning (hence the sometimes heard term "sleeping spinlocks").
Quoted 24 lines
Quoted 15 lines
This means that
interrupts will occur while rtmutexes are held and interrupt handling is a potential preemption point; on return from handling an interrupt, a scheduler check is made as to whether a higher priority thread needs to run.The rtmutex locking construct also has a property known as "priority inheritance", which is a mechanism for avoiding a deadlock situation known as "priority inversion". In order to prevent a low priority thread that is holding a lock from preventing a higher priority thread from running, the low priority thread temporarily inherits the priority of the highest priority thread that is requesting the lock, which allows the low-priority thread to run until it completes its critical section and releases the lock.
Quoted 8 lines
In addition to changing spinlocks, interrupts have been threaded, meaning that instead of handling interrupts in a special "interrupt context", each IRQ has a dedicated thread for running its ISRs. Interrupts go to a common handler and the handler schedules the appropriate thread to handle the interrupt. This means that sleeping spinlocks (rtmutexes) have a context to return to and that interrupt handling can be prioritized by assigning appropriate realtime priorities to the interrupt threads.
Quoted 3 lines
Further, user-level processes may be prioritized above device-level services, allowing computational load and I/O load to be dynamically expedited, partitioned, or decoupled.
You used to work in marketing, didn't you :)
How about:
Further, using realtime priorities, user-level threads may be prioritized *above* certain device level activity, allowing critical application tasks to take precedence over device activity deemed less important.
Clark
Quoted 6 lines · Clark Williams
Quoted 3 lines
Further, user-level processes may be prioritized above device-level services, allowing computational load and I/O load to be dynamically expedited, partitioned, or decoupled.
You used to work in marketing, didn't you :)
No, but I learned English in Germany :)
Quoted 6 lines
How about:
Further, using realtime priorities, user-level threads may be prioritized *above* certain device level activity, allowing critical application tasks to take precedence over device activity deemed less important.
Gets the point across.
Cheers,
Sven
proposed FAQ entry for rt.wiki.kernel.org (v2)
In reply to Clark WilliamsGot some good feedback on the first round, but missed CC'ing rostedt, since he isn't on linux-rt-users, so here's the revised text with the edits from dvhart and sven applied:
---------------------8< snip 8<----------------------------------
Q. How does Real-Time Linux (aka the PREEMPT_RT patch) improve "latency"?
A. The Linux RT patch modifies the behavior of the most common kernel-level locking primitive (the spinlock) and kernel interrupt handling logic, to increase the number of points where a preemption or reschedule may occur. This reduces the amount of time a high priority task must wait to be scheduled when it becomes ready to run, reducing event service time (or "latency").
Most spinlocks in the kernel are converted to a construct called an rtmutex, which has the property of *not* disabling interrupts or preventing task switching while the lock is held. It also has the property of sleeping on contention rather than spinning (hence the sometimes heard term "sleeping spinlocks"). These two properties mean that interrupts may occur while rtmutexes are held and interrupt handling is a potential preemption point; on return from handling an interrupt, a scheduler check is made as to whether a higher priority thread needs to run.
The rtmutex locking construct also has a property known as "priority inheritance", which is a mechanism for avoiding a deadlock situation known as "priority inversion"
(http://en.wikipedia.org/wiki/Priority_inversion). In order to prevent a low priority thread that is holding a lock from preventing a higher priority thread from running, the low priority thread temporarily inherits the priority of the highest priority thread that is requesting the lock, which allows the low-priority thread to run until it completes its critical section and releases the lock.
In addition to changing kernel locking, interrupts have been threaded, meaning that instead of handling interrupts in a special "interrupt context", each interrupt number has a dedicated thread for running its service routines. Interrupts go to a common handler and that handler schedules the appropriate thread to service the interrupt. This means that interrupt service order may be prioritized by assigning appropriate realtime priorities to the interrupt threads. Further, using realtime priorities, user-level threads may be prioritized *above* certain device level activity, allowing critical application tasks to take precedence over device activity deemed less important.
---------------------8< snip 8<----------------------------------
Kinda big for an elevator pitch, but hey, I'm sure the marketing and sales guys will paraphrase it into "It makes things go Real Fast!" :)
Clark
Re: proposed FAQ entry for rt.wiki.kernel.org (v2)
Quoted 36 lines · Clark Williams
Got some good feedback on the first round, but missed CC'ing rostedt, since he isn't on linux-rt-users, so here's the revised text with the edits from dvhart and sven applied:
---------------------8< snip 8<----------------------------------
Q. How does Real-Time Linux (aka the
PREEMPT_RTpatch) improve "latency"?A. The Linux RT patch modifies the behavior of the most common kernel-level locking primitive (the spinlock) and kernel interrupt handling logic, to increase the number of points where a preemption or reschedule may occur. This reduces the amount of time a high priority task must wait to be scheduled when it becomes ready to run, reducing event service time (or "latency").
Most spinlocks in the kernel are converted to a construct called an rtmutex, which has the property of *not* disabling interrupts or preventing task switching while the lock is held. It also has the property of sleeping on contention rather than spinning (hence the sometimes heard term "sleeping spinlocks"). These two properties mean that interrupts may occur while rtmutexes are held and interrupt handling is a potential preemption point; on return from handling an interrupt, a scheduler check is made as to whether a higher priority thread needs to run.
The rtmutex locking construct also has a property known as "priority inheritance", which is a mechanism for avoiding a deadlock situation known as "priority inversion"
(http://en.wikipedia.org/wiki/Priority_inversion). In order to prevent a low priority thread that is holding a lock from preventing a higher priority thread from running, the low priority thread temporarily inherits the priority of the highest priority thread that is requesting the lock, which allows the low-priority thread to run until it completes its critical section and releases the lock.
Quoted 3 lines
In addition to changing kernel locking, interrupts have been threaded, meaning that instead of handling interrupts in a special "interrupt context", each interrupt number has a dedicated thread for running its
s/interrupt number/interrupt line/
Quoted 8 lines
service routines. Interrupts go to a common handler and that handler schedules the appropriate thread to service the interrupt. This means that interrupt service order may be prioritized by assigning appropriate realtime priorities to the interrupt threads. Further, using realtime priorities, user-level threads may be prioritized *above* certain device level activity, allowing critical application tasks to take precedence over device activity deemed less important.
Quoted 4 lines
---------------------8< snip 8<----------------------------------
Kinda big for an elevator pitch, but hey, I'm sure the marketing and sales guys will paraphrase it into "It makes things go Real Fast!" :)
Doesn't it?
<kidding>
-- Steve
Re: proposed FAQ entry for rt.wiki.kernel.org (v2)
Hello,
Quoted 5 lines
Quoted 3 lines
In addition to changing kernel locking, interrupts have been threaded, meaning that instead of handling interrupts in a special "interrupt context", each interrupt number has a dedicated thread for running its
s/interrupt number/interrupt line/
IIRC since .31-rt shared irqs even have one thread for each irq handler. I'm not sure this is worth to be metioned though.
Best regards
Uwe
Signature · 6 lines
Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: proposed FAQ entry for rt.wiki.kernel.org (v2)
Quoted 9 lines · Uwe Kleine-König
Hello,
Quoted 5 lines
Quoted 3 lines
In addition to changing kernel locking, interrupts have been threaded, meaning that instead of handling interrupts in a special "interrupt context", each interrupt number has a dedicated thread for running its
s/interrupt number/interrupt line/
IIRC since .31-rt shared irqs even have one thread for each irq handler. I'm not sure this is worth to be metioned though.
Well, that is going mainline too. We can mention that it is on its way, but only drivers that implement it have it.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
proposed FAQ entry for rt.wiki.kernel.org (v3)
In reply to Clark WilliamsDue to the hue and cry over my inexcusable abuse of OS terminology, here is a rework with the priority inversion section. :)
----------------------8< snip 8<------------------------------
Q. How does Real-Time Linux (aka the PREEMPT_RT patch) improve "latency"?
A. The Linux RT patch modifies the behavior of the most common kernel-level locking primitive (the spinlock) and kernel interrupt handling logic, to increase the number of points where a preemption or reschedule may occur. This reduces the amount of time a high priority task must wait to be scheduled when it becomes ready to run, reducing event service time (or "latency").
Most spinlocks in the kernel are converted to a construct called an rtmutex, which has the property of *not* disabling interrupts or preventing task switching while the lock is held. It also has the property of sleeping on contention rather than spinning (hence the sometimes heard term "sleeping spinlocks"). These two properties mean that interrupts may occur while rtmutexes are held and interrupt handling is a potential preemption point; on return from handling an interrupt, a scheduler check is made as to whether a higher priority thread needs to run.
The rtmutex locking construct also has a property known as "priority inheritance", which is a mechanism for avoiding a condition known as "priority inversion", where a high-priority thread is blocked from executing by lower priority threads holding a shared lock. In order to prevent this condition, the low priority thread holding the lock temporarily inherits the priority of the highest priority thread that is requesting the lock, which allows the low-priority thread to run until it completes its critical section and releases the lock. For more information on priority inversion see:
http://en.wikipedia.org/wiki/Priority_inversion
In addition to changing kernel locking, interrupts have been threaded, meaning that instead of handling interrupts in a special "interrupt context", each interrupt number has a dedicated thread for running its service routines. Interrupts go to a common handler and that handler schedules the appropriate thread to service the interrupt. This means that interrupt service order may be prioritized by assigning appropriate realtime priorities to the interrupt threads. Further, using realtime priorities, user-level threads may be prioritized *above* certain device level activity, allowing critical application tasks to take precedence over device activity deemed less important.
----------------------8< snip 8<------------------------------
Re: proposed FAQ entry for rt.wiki.kernel.org (v2)
In reply to Clark WilliamsQuoted 3 lines · Clark Williams
Got some good feedback on the first round, but missed CC'ing rostedt, since he isn't on linux-rt-users, so here's the revised text with the edits from dvhart and sven applied:
OK, now that the first round of content reviews are complete, here are my gramatical nit-pics. Hey, you asked. ;-)
Quoted 7 lines
---------------------8< snip 8<----------------------------------
Q. How does Real-Time Linux (aka the
PREEMPT_RTpatch) improve "latency"?A. The Linux RT patch modifies the behavior of the most common
s/Linux RT/Real-Time Linux/
Quoted 7 lines
kernel-level locking primitive (the spinlock) and kernel interrupt handling logic, to increase the number of points where a preemption or reschedule may occur.
This reduces the amount of time a high priority
task must wait to be scheduled when it becomes ready to run, reducing
s/high priority/high-priority/
s/when/after/
Quoted 1 line
event service time (or "latency").
This sentence right here is basically the answer, the rest is explanatory. Suggest opening with this:
Real-Time Linux reduces the amount of time a high-priority task must wait to be scheduled after it becomes ready to run, reducing event service time (or "latency").
Quoted 3 lines
Most spinlocks in the kernel are converted to a construct called an rtmutex, which has the property of *not* disabling interrupts or
s/has the property of *not*/does not/ then switch the gerunds to verbs (disabling->disable, etc).
Quoted 1 line
preventing task switching while the lock is held. It also has the
s/It also has the property of/It also/ same gerund->verb switch)
Quoted 2 lines
property of sleeping on contention rather than spinning (hence the sometimes heard term "sleeping spinlocks"). These two properties mean
s/These two properties mean/This means/
Quoted 4 lines
that interrupts may occur while rtmutexes are held and interrupt handling is a potential preemption point; on return from handling an interrupt, a scheduler check is made as to whether a higher priority thread needs to run.
semicolon isn't really necessary here IMO, and it's a long sentence, suggest splitting into two.
the second phrase is very wordy, maybe something more concise? like:
After handling an interrupt, the scheduler checks whether a higher priority task needs to run.
Hrm, actually, I think the second phrase could be eliminated entirely, as it is implicit in "preemption point".
Quoted 2 lines
The rtmutex locking construct also has a property known as "priority
OK, obviously I'm biased against the "has a property" phrase - it seems to drag out the sentence.
Quoted 2 lines
inheritance", which is a mechanism for avoiding a deadlock situation known as "priority inversion"
Deadlock and Priority Inversion are.... wait, we covered this ;-)
Quoted 2 lines
(http://en.wikipedia.org/wiki/Priority_inversion). In order to prevent a low priority thread that is holding a lock from preventing a higher
prevent... from preventing... reads oddly. Maybe replace the first with "avoid"
Quoted 2 lines
priority thread from running, the low priority thread temporarily inherits the priority of the highest priority thread that is requesting
s/that is//
Quoted 1 line
the lock, which allows the low-priority thread to run until it
the lock. The low-priority thread will complete its critical section and release the lock, at which point its original priority will be restored.
Quoted 3 lines
completes its critical section and releases the lock.
In addition to changing kernel locking, interrupts have been threaded,
interrupt handlers have been converted into schedulable threads.
Quoted 1 line
meaning that instead of handling interrupts in a special "interrupt
s/meaning that i/. I/
Quoted 2 lines
context", each interrupt number has a dedicated thread for running its service routines. Interrupts go to a common handler and that handler
s/and that handler/which/
Quoted 6 lines
schedules the appropriate thread to service the interrupt. This means that interrupt service order may be prioritized by assigning appropriate realtime priorities to the interrupt threads. Further, using realtime priorities, user-level threads may be prioritized *above* certain device level activity, allowing critical application tasks to take precedence over device activity deemed less important.
Suggest sticking to "task" or "thread" throughout to avoid confusion.
Thanks,
Darren
Quoted 12 lines
---------------------8< snip 8<----------------------------------
Kinda big for an elevator pitch, but hey, I'm sure the marketing and sales guys will paraphrase it into "It makes things go Real Fast!" :)
Clark
Signature · 3 lines
Darren Hart IBM Linux Technology Center Real-Time Linux Team