Re: RT patch acceptance

[Sven-Thorsten Dietrich <sdietrich@mvista.com>]

On Thu, 2005-05-26 at 16:38 -0400, john cooper wrote:
> Andi Kleen wrote:
> > 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.
> 
> I had brought this up in the dim past in the context
> of adaptive mutexes which could via heuristics decide
> whether to spin/sleep.

> > 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.
> 
> Spin if the lock is contended and the owner is active
> on a cpu under the assumption the lock owner's average
> hold time is less than that of a context switch.  There
> are restrictions as once a path holds an adaptive
> mutex as a spin lock it cannot acquire another adaptive
> mutex as a blocking lock.
> 

It might be simpler to get things working with a basic implementation
first, (status quo), and then look into adding something like this. 

I don't see how this approach decreases the complexity of the task at
hand, especially not in regards to concurrency.

> > 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.
> 
> Yes, I was trying to make that point in an earlier thread.
> 

My original comment was:

> 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..
...
> 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.

The dependency was STATED: "as a logical prerequisite...". 
The context was: "breaking the IRQ threads into a separate patch"

You misread it, and then commented on that. 



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/