Messages in this thread | | | Date | 26 May 2005 21:32:30 +0200 | Date | Thu, 26 May 2005 21:32:30 +0200 | From | Andi Kleen <> | Subject | Re: RT patch acceptance |
| |
On Wed, May 25, 2005 at 11:00:19AM -0700, Sven-Thorsten Dietrich wrote: > > > I have no reason to believe this is any different with all > > this RT testing. > > > > And that's why we have been testing and benchmarking, to > produce number sets that supersede faith, belief, and > conjecture. But ultimately, you can trust your senses, > and I think the audio / video test would allow your eyes > to see, and your ears to hear the difference.
I understand that you have some real improvements that are measurable. What I objected to was the claim that it actually made any difference to interactive users.
> > > -Andi (who also would prefer to not have interrupt threads, locks like > > a maze and related horribilities in the mainline kernel) > > I am definitely for breaking out an IRQ threads patch, > separate from the RT-mutex patches, even if just to > allow examination of that code without the clutter.
What I dislike with RT mutexes is that they convert all locks. It doesnt make much sense to me to have a complex lock that only protects a few lines of code (and a lot of the spinlock code is like this). That is just a waste of cycles.
But I always though we should have a new lock type that is between spinlocks and semaphores and is less heavyweight than a semaphore (which tends to be quite slow due to its many context switches). Something like a spinaphore, although it probably doesnt need full semaphore semantics (rarely any code in the kernel uses that anyways). It could spin for a short time and then sleep. Then convert some selected locks over. e.g. the mm_sem and the i_sem would be primary users of this. And maybe some of the heavier spinlocks.
If you drop irq threads then you cannot convert all locks anymore or have to add ugly in_interrupt()checks. So any conversion like that requires converting locks.
-Andi
- 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/
| |