Re: [patch 00/10] mutex subsystem, -V5

[Christoph Lameter]

On Thu, 22 Dec 2005, Ingo Molnar wrote:

> > I would like some more flexible way of dealing with locks in general. 
> > The code for the MUTEXes seems to lock us into a specific way of 
> > realizing locks again.
> 
> yeah, but we should be careful where to put it: the perfect place for 
> most of these features and experiments is in the _generic_ code, not in 
> arch-level code! Look at how we are doing it with spinlocks. It used to 
> be a nightmare that every arch had to implement preempt support, or 
> spinlock debugging support, and they ended up not implementing these 
> features at all, or only doing it partially.

I think we need to have the ability to modify things on both levels. There 
needs to be a way to introduce f.e. a general HBO type locking algorithm 
for all architectures. But then also a way for an arch to do special
things that are strongly depending on a particular arch like relocating
the actual storage location of a lock to a specially handled memory area.

> i definitely do not say that _everything_ should be generalized. That 
> would be micromanaging things. But i definitely think there's an 
> unhealthy amount of _under_ generalization in current Linux 
> architectures, and i dont want the mutex subsystem to fall into that 
> trap.

The mutex implementation here is one implementation. There needs to be
a generic way to replace this implementation with another in an arch
independent way as well as the ability for an arch to modify low level
elements necessary to optimize locks on a particular hardware.

Then there is the common ground of low level mutexes with spinlocks. So 
far spinlocks also work for semaphores. Now with the MUTEXes we have two 
different locking mechanism that largely overlap in in functionality. In 
the past one could simply replace the spinlock implementation, now one 
also has to worry about MUTEXes.

I wish we had some strategy to make all of this easier and gather common 
elements together.
-
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/