Combining priority concepts of softirqs and rt

["Christian Meier" <chmeie@gmx.com>]

Hi,

I am not sure but I think I am now stuck at some kind of conceptional
problem of softirqs in combination with rt-tasks.

Imagine a system with only three relevant kernel modules A, B and C.
Each uses an own irq and an own tasklet.
Additionally there are two realtime applications named APP_A and APP_B.
APP_A only depends on module A.
APP_B only depends on module B.

APP_B and B should not defer any action of APP_A and module A.
Module C should not defer anything of A, APP_A, B and APP_B.

Example of resulting priority layout:
IRQ-Thread of module A has prio 80
Process APP_A has prio 70
IRQ-Thread of module B has prio 60
Process APP_B has prio 50
IRQ-Thread of module C has prio 40
ksoftirqd has prio 2 ???

As long as irq action of A can be handled without any tasklet action,
everything will be fine.
But when A's tasklet is scheduled, irq of B, APP_B and irq of C can defer
A's tasklet.

Moving the ksoftirqd prio higher omits the problem, but creates other
problems, for example:
IRQ-Thread of module A has prio 80
Process APP_A has prio 70
ksoftirqd has prio 65
IRQ-Thread of module B has prio 60
Process APP_B has prio 50
IRQ-Thread of module C has prio 40

Now tasklets of C can defer APP_B and IRQ-thread of B.

My first thought was:
Shouldn't it be possible to use rt-priority of the irq that activated the
tasklet to sort the softirqd queue and additionally inherit the currently
highest priority of the tasklet queue to the softirqd thread priority?

But then I noticed that this would be almost identical to throw away the
ksoftirqd and execute all tasklets directy after finishing the workload if
the irq that scheduled the tasklet is finished.

So my resulting question is:

Wouldn't it be possible to completely run softirqs and tasklets directly in
irq thread context after finishing the irq handler?
As softirqs can run at the same time on more than one cpu but only once on a
single cpu, this would apply to the irq-thread semantics.
Additionally to get tasklet semantics (only one tasklet of the same type at
a given time on all cpus) a tasklet specific spinlock_t could be used as a
wrapper around the call to the tasklet code.
Would this break anything else?

Thanks