Re: [patch 04/15] Generic Mutex Subsystem, add-atomic-call-func-x86_64.patch
From: Ingo Molnar
Date: Wed Dec 21 2005 - 01:00:37 EST
* Linus Torvalds <torvalds@xxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/