User: Password:
Subscribe / Log in / New account

The realtime preemption endgame

The realtime preemption endgame

Posted Aug 5, 2009 20:55 UTC (Wed) by glikely (subscriber, #39601)
Parent article: The realtime preemption endgame

From Paragraph 5: "... If a given driver explicitly requests a threaded handler, behavior is similar to a non-realtime kernel; the driver's "hard" interrupt handler runs as usual in IRQ context."

For those who were confused by this, as I was, this post from tglx may help:

Drivers which request threaded irq handlers actually register 2 handlers in the call to request_threaded_irq(). The primary or "hard" handler runs at the usual IRQ contex, and it checks if the IRQ originated from the device. If so it masks out the IRQ at the device level and returns IRQ_WAKE_THREAD. Then the generic IRQ code can wake the thread that runs the threaded handler.

In the realtime context, it doesn't make sense to run the "hard" handler in a thread since it is already designed to be low latency and it would just turn around and ask for another thread to be scheduled anyway. Plus, since the hard handler masks the IRQ at the device level, the generic IRQ code can leave the irq line unmasked so that IRQs from other devices on the same line don't have to get inhibited also.

Not knowing this background, the paragraph from the article sounded like drivers requesting a threaded handler would get the old non-threaded behaviour. Hence my confusion.

(Log in to post comments)

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds