proposed FAQ entry for rt.wiki.kernel.org

proposed FAQ entry for rt.wiki.kernel.org

[Clark Williams]

[-- Attachment #1: Type: text/plain, Size: 2366 bytes --]

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. 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: proposed FAQ entry for rt.wiki.kernel.org

[Darren Hart]

Clark Williams wrote:
> 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.

> 
> 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".

> 
> 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". 

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

> 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. 

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?


-- 
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team

Re: proposed FAQ entry for rt.wiki.kernel.org

[Sven-Thorsten Dietrich]

On Thu, 2009-10-22 at 12:08 -0500, Clark Williams wrote:
> 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?"

> 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..."

>  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. 

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.

Re: proposed FAQ entry for rt.wiki.kernel.org

[Clark Williams]

[-- Attachment #1: Type: text/plain, Size: 4147 bytes --]

On Thu, 22 Oct 2009 11:16:27 -0700
Darren Hart <dvhltc@us.ibm.com> wrote:

> Clark Williams wrote:
> > 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.
> 
> > 
> > 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".

How's this:

Q. How does Real-Time Linux (aka the PREEMPT_RT patch) 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". 
> 
> 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

Yeah, I didn't want to get into a full-on discussion of priority
inversion, so a reference is a good idea.

> 
> > 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. 
> 
> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: proposed FAQ entry for rt.wiki.kernel.org

[Clark Williams]

[-- Attachment #1: Type: text/plain, Size: 3773 bytes --]

On Thu, 22 Oct 2009 11:18:23 -0700
Sven-Thorsten Dietrich <sven@thebigcorporation.com> wrote:

> On Thu, 2009-10-22 at 12:08 -0500, Clark Williams wrote:
> > 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.

> 
> > 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..."
> 

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"). 


> >  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. 
> 
> 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
 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: proposed FAQ entry for rt.wiki.kernel.org

[Darren Hart]

Clark Williams wrote:
> How's this:
> 
> Q. How does Real-Time Linux (aka the PREEMPT_RT patch) improve
> "latency"?

Works for me

>> 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.

-- 
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team

Re: proposed FAQ entry for rt.wiki.kernel.org

[Sven-Thorsten Dietrich]

On Thu, 2009-10-22 at 13:41 -0500, Clark Williams wrote:
> > 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 :)

> 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)

[Clark Williams]

[-- Attachment #1: Type: text/plain, Size: 2783 bytes --]

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_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




	

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: proposed FAQ entry for rt.wiki.kernel.org (v2)

[Steven Rostedt]

On Thu, 2009-10-22 at 15:25 -0500, Clark Williams wrote:
> 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_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

s/interrupt number/interrupt line/

> 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!" :)

Doesn't it?

<kidding>

-- Steve

proposed FAQ entry for rt.wiki.kernel.org (v3)

[Clark Williams]

[-- Attachment #1: Type: text/plain, Size: 2651 bytes --]

Due 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<------------------------------



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: proposed FAQ entry for rt.wiki.kernel.org (v2)

[Darren Hart]

Clark Williams wrote:
> 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. ;-)

> 
> ---------------------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

s/Linux RT/Real-Time Linux/

> 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/

> 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").

> 
> 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).

> 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)

> 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/

> 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".

> 
> 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.

> inheritance", which is a mechanism for avoiding a deadlock situation
> known as "priority inversion"

Deadlock and Priority Inversion are.... wait, we covered this ;-)

> (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"

> priority thread from running, the low priority thread temporarily
> inherits the priority of the highest priority thread that is requesting

s/that is//

> 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.

> 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.

> meaning that instead of handling interrupts in a special "interrupt

s/meaning that i/. I/

> 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/

> 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

> 
> ---------------------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
> 
> 
> 
> 
> 	


-- 
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team

Re: proposed FAQ entry for rt.wiki.kernel.org (v2)

[Uwe Kleine-König]

Hello,

> > 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

-- 
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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: proposed FAQ entry for rt.wiki.kernel.org (v2)

[Steven Rostedt]

On Fri, 2009-10-23 at 10:11 +0200, Uwe Kleine-König wrote:
> Hello,
> 
> > > 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html