softirq in rtems

[Pavel Pisa]

Hello Chan Kim,

On Wednesday 17 of June 2015 10:57:11 Chan Kim wrote:
> Hi,
> In linux, we can defer some works in interrupt service routine to softirq.
> (linux has about 7 softirqs, including network TX, network RX, tasklet
> among them). I try to move some code in linux SD card host controller
> driver to RTEMS but I don't know how to implement tasklet in RTEMS. (I want
> to do some time consuming working in tasklet by just scheduling it to be
> done in tasklet during ISR) In RTEMS, do we have a convenient tool like
> softirq in linux? Otherwise, I will have to do it all in ISR or make a
> separate task and use some variables to start the time-consuming task in
> the thread. Thanks in advance.

Generally, I suggest to not introduce Linux kernel soft IRQ
mechanism/execution context.

You stumble over it in all possible directions and in real-time
paths it is even more critical and harmfull. Soft IRQ has been
introduced into Linux to solve problem when some driver
processing takes so long that it does not fit in hard IRQ
processing and due to extreme latencies of kernel code/scheduler
(original kernel space has been non preemptive design) the time
to react from kernel thread was above acceptable time for device
(i.e. data lost or really bad throutghput).
At the end, Linux kernel adapted to fully preemptive/RT variant
moves complex way spaghetti ISR processing to RT threads and
soft-irq to other lower priority threads which are shared
between drivers.

The correct solution is to really kept ISR extremely short (ideally
only disable IRQ source in the device register and release worker
thread waiting on semaphore or in RTEMS possibly even on event).
There should be worker thread for each device if its use in RT
path is possible to allow to tune priorities right way.
If it is non critical subsystem then worker thread can handle
multiple devices or can handle soft IRQ or other work queue
(in Windows world called DPC - deferred procedure calls).
Due to bad design of many Linux drivers live with long ISR
code is inevitable.

Problem is solved for Linux RT by that complex moving original
IRQ code to per IRQ threads and adding that fast accept+disable
IRQ to core infrastructure. Result is that on RT aware Linux,
spinlock is in the fact mutex, IRQ is worker thread etc.
So unexperienced programmer is lost in the misleading terms
even that real design is quite capable. Some parts, like
networking stack, are a little faster thanks to soft-IRQs
which does not need kernel thread switching on non-RT
build but it makes maintainers of RT variant continuous
depression due to hidden deadlocks and has significant latencies.

If quality and model of RTEMS drivers is kept correct then
all this is not required. If you want to use code, model, approach
based on Linux drivers then try to move whole driver ISR
processing to thread and place only that thread wake into ISR.
Then find bare minimum to protect CPU infinite processing of
ISR by moving exactly that minimal part which inactivate IRQ
to ISR.

Unfortuantelly, I have fear from some RTEMS standard driver
in this respect. I.e. serial port processing has to large
part in ISR. But problem is that serial port is required
for console and debugging (i.e. to send and collect received
data even when system is in troubles/overloaded) and quite
often data has to be taken from hardware quite quickly to
not been overwritten (10kHz for 115.2 kBaud without FIFO).
So this one is quite problematic and may it be deserves
an exception. But for RT OS it is not good and should
be avoided as much as possible.

Best wishes,

              Pavel