the thread with subject "LL/SC benchmarking" in mid July
died away, since I was busy doing more pressing things.
To refresh your memory:
The NEC VR41xx CPU has no LL/SC instructions, so they must
be emulated by the kernel, which slows down the test-and-set
and compare-and-swap operations (used by linux-threads)
considerably. For the VR41xx (and other CPUs which have
branch-likely instructions), there exisits a workaround
which enables userspace-only atomic operations, with minor
help from the kernel: The kernel must guarantee that register
k1 is not equal to some magic value after every transition
Two things were left open in July:
- find out the minimal amount of changes to the kernel
to guarantee k1 != MAGIC after eret
- determine how to tell glibc to use the branch-likely
workaround instead of emulated LL/SC
I looked through the kernel code, and I think that
arch/mips/mm/tlbex-r4k.S always leaves the last value
from CP0_ENTRYLO in k1, thus bit 31 of k1 is guarateed
to be zero.
The other interrupt and exception handlers seem to
be too complex to make any guarantees about the value left
in k1, so I added a 'move k1,$0' to RESTORE_SP_AND_RET
in include/asm-mips/stackframe.h, and conditionalized
it via CONFIG_MIPS_USERSPACE_ATOMIC_OPS.
To tell glibc about the support for the branch-likely
workaround I added a sysctl.
A few things:
- I couldn't come up with a better name for the config
option and sysctl.
- If glibc were to use sysctl(2) to query for
mips_userspace_atomic_ops, glibc would depend on
linux/sysctl.h from the very newest kernel, which
is bad; maybe glibc should just query for exisitence
of the file /proc/sys/kernel/mips_userspace_atomic_ops?
Or maybe we should just add a /proc/foobar instead
of a sysctl?
- Maybe I should add some comments to tlbex-r4k.S so
no-one accidentally breaks the k1 < 0x80000000 assertion?
Please comment on the appended patch.
If we could agree the kernel support for this, I would
prepare a matching glibc patch.
Description: Text document