[Top] [All Lists]

Re: MIPS_ATOMIC_SET again (Re: newest kernel

To: Jun Sun <>
Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel
From: Florian Lohoff <>
Date: Wed, 23 May 2001 20:54:12 +0200
Cc: Joe deBlaquiere <>, "Maciej W. Rozycki" <>,, Pete Popov <>, George Gensure <>,
In-reply-to: <>; from on Wed, May 23, 2001 at 11:41:57AM -0700
Organization: rfc822 - pure communication
References: <> <> <>
User-agent: Mutt/1.3.15i
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.

Florian Lohoff                     +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

<Prev in Thread] Current Thread [Next in Thread>