Re: [patch 04/15] Generic Mutex Subsystem, add-atomic-call-func-x86_64.patch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

* Linus Torvalds <[email protected]> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux