Andrew Morton <[email protected]> wrote: > > David Howells <[email protected]> wrote: > > > > So... Would you then object to an implementation of a mutex appearing in the > > tree which semaphores that are being used as strict mutexes can be migrated > > over to as the opportunity arises? > > That would be sane. > But not very. Look at it from the POV of major architectures: there's no way the new mutex code will be faster than down() and up(), so we're adding a bunch of new tricky locking code which bloats the kernel and has to be understood and debugged for no gain. And I don't buy the debuggability argument really. It'd be pretty simple to add debug code to the existing semaphore code to trap non-mutex usages. Then go through the few valid non-mutex users and do: #if debug sem->this_is_not_a_mutex = 1; #endif - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- From: Thomas Gleixner <[email protected]>
- Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- From: Steven Rostedt <[email protected]>
- Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- References:
- Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- From: Andrew Morton <[email protected]>
- Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- From: Alan Cox <[email protected]>
- Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- From: David Howells <[email protected]>
- Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- From: Paul Jackson <[email protected]>
- Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- From: Paul Jackson <[email protected]>
- [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- From: David Howells <[email protected]>
- Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- From: Andrew Morton <[email protected]>
- Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- From: Ingo Molnar <[email protected]>
- Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- From: Christoph Hellwig <[email protected]>
- Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- From: Ingo Molnar <[email protected]>
- Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- From: Ingo Molnar <[email protected]>
- Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- From: David Howells <[email protected]>
- Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- From: David Howells <[email protected]>
- Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- From: David Howells <[email protected]>
- Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- From: Thomas Gleixner <[email protected]>
- Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- From: Mark Lord <[email protected]>
- Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- From: David Howells <[email protected]>
- Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- From: Andrew Morton <[email protected]>
- Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- Prev by Date: Re: [ckrm-tech] Re: [RFC][patch 00/21] PID Virtualization: Overview and Patches
- Next by Date: agpgart.ko can't be unloaded
- Previous by thread: Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- Next by thread: Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
- Index(es):