[Top] [All Lists]

Once again: test_and_set for CPUs w/o LL/SC

Subject: Once again: test_and_set for CPUs w/o LL/SC
From: Johannes Stezenbach <>
Date: Mon, 16 Sep 2002 18:40:34 +0200
Original-recipient: rfc822;
User-agent: Mutt/1.4i

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
to userspace.

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

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.


Attachment: linux-oss-nollsc.patch
Description: Text document

<Prev in Thread] Current Thread [Next in Thread>
  • Once again: test_and_set for CPUs w/o LL/SC, Johannes Stezenbach <=