Hello,
On Wed, Jun 17, 2009 at 1:21 PM, Remy Bohmer<linux@xxxxxxxxxx> wrote:
> Thread-ids can/will vary, and a lot of scripting is needed to map the
> proper interrupt handler of the right device driver to the proper
> kernel thread, and to set the priorities accordingly.
> And what if there is not a userland at all? and init is the only
> process in the system, or there is no shell installed?
> Or some kernel developer change the name of the interrupt handler? All
> different implementations in userspace has to follow as well... And
> why is 50 the right default to use, and not 30 or 60?
> For a realtime embedded device this could all be the case, and it is
> not that strange.
>
To make sure the end solution covers all use cases, I re-submit my case:
>From my email: "[PATCH 2.6.24.7-rt14 v2] rt:
{queue,schedule}_work_prio() allowing work priorities other than
caller's priority".
"Adds schedule_work_prio() and queue_work_prio() so that work can be
scheduled with a different priority than the caller.
Currently under PREEMPT RT, queue_work() and therefore schedule_work() makes
the work inherit the caller's priority.
However, if a real-time kernel interrupt handler thread defers work it may want
the deferred work have lower priority so it does not contend for the CPU with
succeeding interrupt handling. In the non real-time kernel, this was guaranteed
because interrupts preempt workqueues.
The faulty case was a non-FIFO serial driver that deferred LED blinking to
a workqueue using schedule_work(). However, that work used GPIO bitbanged I2C,
which uses 50 usecs udelay()s. With the work inheriting the serial IRQ priority,
it easily missed the ~60 usec deadline of 115200 bps communications.
This patch solves the issue by introducing and using schedule_work_prio()."
Basically, what I did to fix our system, was run the workqueue with
lower priority (current - 1) than the interrupt handler.
So that when the interrupt handler started the work on the queue, that
work would not increase interrupt service latency.
What would be the solution forward for this case, for mainlined
drivers having the same problem?
Regards,
--
Leon
--
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
