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
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
