Hello Darren, Juergen and Ingo,

quoted

All I need is one IRQ at priority 51, all other can still run at 50. And I
don't want to search at system's runtime for the right PID of driver's
thread to set its priority via "chrt". There is no user at this system, its
an embedded one.

It seems reasonable then, for such a specialized case, to consider Remy's
reply to my previous mail:

"To suit my needs, I did this by just patching the kernel thread
priorities at the places where they are started.

Attached I have put my patch to change the priorities of the
soft-irq's and the IRQ threads.
Maybe Juergen can use it so suit his needs. (Sorry for attaching
instead of inlining, but I have not find a way to inline a patch
without corrupting it while using Gmail from within Firefox)

But, I think that the mechanism to change the soft-irq priorities can
be integrated in the mainline RT-patch, I have modified the
softirq_info struct with the soft-irq thread names such that it also
contains the thread priority per soft-irq. For customisation it is
easier to adapt this struct, than to apply the entire patch over and
over. Until now the code seems to change that frequently that I have
to reimplement this patch over and over...

Maybe Ingo can look at it, and find a way to implement it more
generic? (In the softirq_info struct we could default set all prios
back to 50, and than from functional point of view there will be no
change for other RT-patch users, but makes Embedded-users life easier.

While looking at the IRQ-threads: Notice that setting all IRQ-threads
priorities to 50 with SCHED_FIFO is a bit strange to begin with,
because on a non-RT kernel all IRQ's have different priorities and a
higher prio irq can preempt a lower prio one. (on X86) The current
implementation will not preempt another irq-thread due to the same
prios and fifo scheduling.
The implementation I have in this patch follows the original behaviour
more closely, but changing that also could lead to some discussion...

Kind Regards,

Remy