This patch set allows to have inlined spinlocks again.
V2: rewritten from scratch - now also with readable code
V3: removed macro to generate out-of-line spinlock variants since that
would break ctags. As requested by Arnd Bergmann.
V4: allow architectures to specify for each lock/unlock variant if
it should be kept out-of-line or inlined.
V5: simplify ifdefs as pointed out by Linus. Fix architecture compile
breakages caused by this change.
V6: rename __spin_lock_is_small to __always_inline__spin_lock as requested
by Ingo Molnar. That way it is more consistent with the other methods
used to force inlining.
Also simplify inlining by getting rid of the old variants to force
inlining of the unlock functions.
This is hopefully the final version. I did again run the whole cross
compiles. The patch set applies on top of latest Linus' git tree, but
also applies on top of linux-next.
Ingo, I assume you don't have further objections?
Should this go in via -mm then?
---
The rationale behind this is that function calls on at least s390 are
expensive.
If one considers that server kernels are usually compiled with
!CONFIG_PREEMPT a simple spin_lock is just a compare and swap loop.
The extra overhead for a function call is significant.
With inlined spinlocks overall cpu usage gets reduced by 1%-5% on s390.
These numbers were taken with some network benchmarks. However I expect
any workload that calls frequently into the kernel and which grabs a few
locks to perform better.
The implementation is straight forward: move the function bodies of the
locking functions to static inline functions and place them in a header
file.
By default all locking code remains out-of-line. An architecture can
specify
#define __always_inline__spin_lock
in arch/<whatever>/include/asm/spinlock.h to force inlining of a locking
function.
defconfig cross compile tested for alpha, arm, x86, x86_64, ia64, m68k,
m68knommu, mips, powerpc, powerpc64, sparc64, s390, s390x.
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
