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

["Kevin D. Kissell" <kevink@mips.com>]

> Hi all,
> 
> On Mon, Sep 16, 2002 at 06:40:34PM +0200, I wrote:
> > 
> > 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
> 
> Since there have been no follow-ups I must assume that
> this topic is no longer of interest. Is this so? Or
> is the way I approach it deemed inappropriate?

When I first proposed the branch-likely hack last winter,
I thought it might be worth while to do a through code
inspection to determine what set of values could never
be returned in k1 (or k0 for all I care) if an exception
was taken, such that there would be no mods to the
kernel required whatsoever.  I spent a little time going 
down that path, and it does look at first glance as if one 
could guarantee that one will never come out of an exception 
with k1 equal to 0xffdadaff in current oss/linux-mips cvs
sources, but the guys at Sony, who have a big interest in 
this technique, given that the PS2 has no LL/SC,
prefered a more conservative approach which explicitly
clobbered the selective register on all exceptions,
even if it meant some small performance impact.
That's probably going to be a more reliable design,
though I would still consider leaving the TLB refill handler
untouched and counting on the fact that k1 must contain
a non-lethal EntryLo value on return from the exception.

As for glibc, the possibilities are numerous and I'm not
the guy who'd have to make it work.

            Regards,

            Kevin K.