Re: [patch] IRQ threads

[hui]

On Wed, Jul 28, 2004 at 05:48:36PM -0400, Karim Yaghmour wrote:
> Two things:
> - What I'm suggesting is a nanokernel-based N kernel scheme, not the
> dual kernel scheme (which is patented BTW).
> - There's only one company out there that is known to sell proprietary
> products around the dual kernel approach, and it isn't mine.

I have to say that I didn't really carefully read the papers for
your stuff and I still don't exactly understand what's going on
with your nanokernel. It sounds interesting, but it doesn't solve
what I think are inescapable preemption problems with the Linux
kernel.

> Indeed. So the question now becomes: is it worth introducing that much
> complexity inside the kernel to solve a problem that matters only
> marginally to server and workstation users? It's already difficult as it
> is to manage the preemption, do we really want to go the full way with
> threaded int handlers and mutexes instead of locks?

Complexity is a kind of relative terms in this conversation. It's
more of a function of what one is uses here verses what other folks
have been doing outside of Linux. I personally don't think it's THAT
hard. It's just that folks inside Linux have really gotten comfortable
using spinlocks for everything instead of another style of thinking.
It's all learnable after you get over the shock and not as hard as
folks think it would be.

> What I'm suggesting is a very simple model that solves 90% of the time-
> sensitive problems I have seen with Linux: Use the Adeos nanokernel to
> implement the real-time component of drivers as a priority domain the
> interrupt pipeline. Hence, instead of the current driver model:
> 1- Int handler
> 2- BH/SoftIRQ/etc.
> We get:
> 1- Hard-rt handler
> 2- Normal Linux handler
> 3- BH/SoftIRQ/etc.

I don't immediately see why this is going to give us hard RT for Linux
applications. I'd like a short explanation if you have time to reply
to this.

> This is even without any RTAI/RTL or anything of that kind.
> 
> And for the rest, then you want to have a look at Philippe Gerum's
> ongoing RTAI-fusion work. With RTAI-fusion, you get the same normal
> Linux ABI for all user-space tasks, but you get hard-rt for free.
> Practically, normal Linux calls are caught and run through RTAI
> instead of Linux. Philippe has already got the standard nanosleep()
> running in hard-rt. So the question is therefore straight-forward:
> should we engineer a path for converting the entire kernel to hard-rt
> or do we keep the kernel as it was designed and add the necessary
> mechanisms for obtaining hard-rt using things that were made to
> provide it by design?

I don't really understand what RTAI fusion is and I would like
some pointers to this. I've read the web page for this, but I wasn't
able to extract a good chunk of information that would give me a
clear picture of what it does.
 
> I personally believe that the added complexity does not benefit
> Linux. I may yet be shown wrong, but with what we can currently do
> with plain vanilla Adeos, and where RTAI/fusion is heading, the
> problem space of applications which can't be serviced by this
> combination is getting increasingly limited.

Well, you have to think of it in a wider scope for a bit. If you
want rate-guarateed streaming partition support from SGI's XFS,
touching dcache, VM, etc... then you have to dealing with
non-preemptable locking throughout the Linux kernel, no choice.
Having a pervasive model is a superior solution to dual kernels
since you have the full support of Linux verses the constrained
semantics and APIs of a controlled sub-domain. That typically needs
to be temporarly buffered (and API) both in and out of the a
Linux sub-system. I fail to see how a nano-kernel, RTAI and other
supporting kernel sub-systems can get around this problem without
solving preemption issues within Linux.

When you think of things like this you have to think of what's
happening now with applications that include the traditional RT
stuff as well as media driven apps, which are becoming more and
prevalent as little things like cell phone devices get more and
more bandwidth. For media driven applications, none of the
secondary/dual kernel or things like that can properly deal with
things like IO thread/channel bonding, which depends on various
IO layers that touch many SMP locked critical sections/systems
in the kernel. Running into Linux's SMP locking logic in these
cases are inescapable, so I don't see a choice but doing some
kind of full lock conversion.

Anytime you have an application that uses a full suite of Linux
facilities will have this problem. It just hasn't been done for
a 2.6 kernel just yet.

bill

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/