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

[Johannes Stezenbach <js@convergence.de>]

On Mon, Oct 07, 2002 at 06:21:52PM +0200, Kevin D. Kissell wrote:
>
> 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.

In my original posting from Mon, Sep 16, 2002 (maybe I should
have reposted it in full?), a had appended a patch which
leaves the TLB handlers alone (k1 always ends up with an EntryLo value,
thus bit 31 is guaranteed to be 0), but explicitly sets k1 to zero in
RESTORE_SP_AND_RET.

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

The question is how the glibc can detect if
a) the CPU does not have LL/SC
b) the kernel guarantees k1 != MAGIC

I think the kernel should announce this explicitly.
In my patch from Sep 16 I used a sysctl, but that's
probably bad because glibc would rely on a real new
include/linux/sysctl.h.

I need some advice on this (maybe add a line to /proc/cpuinfo,
or create a new /proc entry? or add a sysmips call to get
this info?).

I also want to know if there's public interest to get such
a change in the kernel. If yes, I will try to get a matching
patch into glibc. If no, I will just post the current patch I
use to the list for the hackers to pick up.


Regards,
Johannes