Re: RT patch acceptance

[Sven Dietrich <sdietrich@mvista.com>]

Andrew Morton wrote:

> Daniel Walker <dwalker@mvista.com> wrote:
>  
>
> > I'm not going to ignore any of the discussion, but it would be nice to
> > hear Andrew's, or Linus's specific objections..
> >    
> This thing will be discussed on a patch-by-patch basis.  Contra this email
> thread, we won't consider it from an all-or-nothing perspective.
>
> (That being said, it's already a mighty task to decrypt your way through
> the maze-like implementation of spin_lock(), lock_kernel(),
> smp_processor_id() etc, etc.  I really do wish there was some way we could
> clean up/simplify that stuff before getting in and adding more source-level
> complexity).
>
>  
The IRQ threads are actually a separate implementation.

IRQ threads do not depend on mutexes, nor do they depend
on any of the more opaque general spinlock changes, so this
stuff SHOULD be separated out, to eliminate the confusion..

There was an original IRQ threads submission by
John Cooper/ TimeSys, about a year ago, which Ingo
subsequently rewrote.

The original MV RT-kernel contribution provided separate patches
for IRQ threads, based on Ingo's VP work.

Even Ingo's current IRQ thread implementation,
which provides a /proc interface to pop IRQs in and out of threads,
does not depend on any of the more complex RT-mutex related stuff.

And Ingo's IRQ threads implementation hasn't substantially
changed in close to a year now.

In that sense, Daniel's original query focuses on IRQ threads.

Its up to Ingo if he wants to break that out as a separate patch, again.

I think people would find their system responsiveness / tunability
goes up tremendously, if you drop just a few unimportant IRQs into
threads.

As a logical prerequisite to the Mutex stuff, the IRQ threads, if broken 
out,
could allow folks to test the water in the shallow end of the pool.

Give this technology some run-time, get everyone happy with it,
reduce the patch size for RT, and get the Arm folks, a.o. on generic IRQs,
then lets deal with the other pieces of RT, in a nice overseeable fashion.



Sven

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