Messages in this thread | | | Date | Wed, 21 Dec 2005 07:00:37 +0100 | From | Ingo Molnar <> | Subject | Re: [patch 04/15] Generic Mutex Subsystem, add-atomic-call-func-x86_64.patch |
| |
* Linus Torvalds <torvalds@osdl.org> wrote:
> If it had _started_ with a mutex implementation that was faster, > simpler, and didn't rename the old and working semaphores, I'd have > been perfectly fine with it.
oh, i'm totally OK with not doing the renames and leaving semaphores alone!
Just in case it wasnt clear: i very much expected that the migration helper patches would be controverial, and that they would probably not go upstream. [Christoph said last week that they were fit for an obfuscated C contest, not the kernel, and i didnt expect this sentiment to change overnight.] Look at my patch order:
xfs-mutex-namespace-collision-fix.patch
add-atomic-xchg-i386.patch add-atomic-xchg-x86_64.patch add-atomic-xchg-ia64.patch add-atomic-call-func-i386.patch add-atomic-call-func-x86_64.patch add-atomic-call-func-ia64.patch add-atomic-call-wrappers-all-other-arches.patch
mutex-core.patch
mutex-debug.patch mutex-debug-more.patch
mutex-migration-helper-i386.patch # not upstream from here mutex-migration-helper-x86_64.patch mutex-migration-helper-ia64.patch mutex-migration-helper-core.patch
sx8-sem2completions.patch cpu5wdt-sem2completions.patch ide-gendev-sem-to-completion.patch loop-to-completions.patch
arch-semaphores.patch
The first 11 patches are finegrained and contain _zero_ of the migration and rename stuff. I specifically created the patch-series in such a way, so that we could simply chop off the last few patches.
in the future i'll only send patches up to mutex-debug-more.patch, as suggested by Christoph and you as well. So there's really no controversy. Btw., that was true for my first queue already, as noticed by Christoph [*].
Basically all of the activity in the last 2 days was in the first 11 patches. I'll send an updated queue later today.
Ingo
[*] the migration helpers were incredibly useful for pulling this off. Without the wide exposure of mutexes to existing semaphore users i'd not have been able to profile the system, to measure the impact the effects of mutexes on performance. I'd also not have been able to say what percentage of semaphores could move over to mutexes. We could also not have carried the mutex implementation in the -rt tree for more than a year, in which year millions of lines were changed in the upstream kernel! It would have been simply impossible to even attempt this, without the type-sensitive APIs and the minimal renames to categorize semaphores. - 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/
| |