On Wed, May 23, 2001 at 11:41:57AM -0700, Jun Sun wrote:

Like I said in the previous email, ll/sc emulation is at least twice as bad as
sysmips().  The likely failure of sc will make the performance even worse.  In
addition, the new glibc starts to pthread massively now (try 'ls' and you will
see). I do think performance is a factor here.

There are a lot of glibc issues to have a look at - Try issueing a "sleep"
compiled against glibc 2.2 and you'll see at least 20-30 sysmips/shed_yield
calls. As for sleep this is completely unecessary but i guess this
is common glibc startup code and on most architectures atomic test/set
instructions are not as painful as on non ll/sc mips cpus.

I see the trouble of having extra configurations.  If you were planning to
have separate support for MIPS I and MIPS II systems, you should be covered. 
After all there are only limited number of variants anyway - so far. :-)

My favourit would be to let the glibc on runtime decide whether
to use sysmips or ll/sc in the atomic test_and_set stuff. This would
lead to an common atom op in the userspace which is fast on ll/sc 
cpus and gives much lesser performance penaltys in the sysmips case
than emulating ll/sc.

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?