Subject: Re: userspace spinlocks

From: Ralf Baechle <[email-masked]>
Date: Wed, 1 Nov 2000 14:36:11 +0100

On Tue, Oct 31, 2000 at 10:50:39PM -0800, Mike Klar wrote:

> > BTW, I didn't know the kernel already has ll/sc emulation.  That seems
> > to be necessary, even just for the binary compability sake.
> 
> It's not complete in the Linux-MIPS tree, it is at least more so in the
> Linux VR tree, but still only supports locking between user contexts.  Patch
> is below, sorry if it doesn't apply cleanly, there were a few bits that I
> cut out that weren't pertinent to LL/SC.
> 
> The bits that have to do with ll_task in the below patch look wrong, though,
> and I only just noticed when preparing this patch that it had gotten added.
> I'm not sure what the motivation for adding it was, maybe clearing ll_bit
> only on context switches was not sufficient to cover all cases (like thread
> creation, maybe?), but I thought I had looked into that already.

Ok, I'll take this and try to hack it into shape.  I especially don't
like putting anything into the scheduler - another 5 ns for a 200MHz box
per cotext switch go down the drain.  For sanity reasons I also think we
don't want to support SMP for the ll/sc emulation.

  Ralf

---

From: "Mike Klar" <[email-masked]>
Date: Wed, 1 Nov 2000 08:40:30 -0800

Ralf Baechle wrote:

> per cotext switch go down the drain.

I agree that's pretty nasty, but I don't see any other way to break the link
on context switches that doesn't also add the same overhead (if not more).
The worst part of it is the extra store per context switch happens even if
you don't ever use ll/sc.

You could probably implement locking primitives without it, but then you're
getting away from actually emulating ll and sc.  I guess that's not a big
deal, since we're already not emulating them 100%, but the further you get
from the actual functionality of the instructions, the more likely it is to
break some user space code when someone decides to be "clever" with ll/sc by
using them per the hardware ll/sc specification.

Then again, I'm just ranting here, since the clear-it-in-the-resume-function
approach apparently wasn't doing what it should have 100% anyway.

> For sanity reasons I also think we

I agree.  It's not impossible to do, but very much non-trivial, for
something that will probably never be used anyway.  The embedded R4K CPUs
that I've seen without ll/sc give lack of SMP support as the reason for not
implementing ll/sc.  Sigh... as if uniprocessor systems never need locking
primitives....

Mike K.