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?
