Re: RT patch acceptance

[Thomas Gleixner <tglx@linutronix.de>]

On Thu, 2005-05-26 at 22:27 +0200, Andi Kleen wrote:
> I really dislike the idea of interrupt threads. It seems totally
> wrong to me to make such a fundamental operation as an interrupt
> much slower.  If really any interrupts take too long they should
> move to workqueues instead and be preempted there. 

I don't see a real good argument why an interrupt is such a fundamental
operation which has to be treated seperately. It is a computation type
with a set of constraints. It depends on your system requirements which
importance and execution mechanism you select for the computation in
order to fulfil the constraints.

If you want deterministic control in an OS you have to control _all_
computation types by the scheduler. IRQ to thread conversion is one of
many mechanisms to gain control over the execution behaviour of
interrupt type computations. It has an nice advantage over other
mechanisms as it is simple to understand; people are used to deal with
threads and priorities.

> But keep
> the basic fundamental operations fast please (at least that used to be one
> of the Linux mottos that served it very well for many years, although more
> and more people seem to forget it now) 

"It has been that way since ages" arguments are not really productive in
a discussion. If you look at the history of Linux over the years, many
things which seemed to be untouchable have been changed in order to make
it usable for specific application types.

Linux deals quite well with a broad range of application scenarios and
there is quite a lot of interest from industrial users to have RT
features included. Sure you may argue that the addon solutions,
nanokernel approaches are available for that, but industrial users are
looking for a scalable all in one solution, where they can turn on the
features they need for the specific application.


tglx