linux-mips
[Top] [All Lists]

Re: MIPS_ATOMIC_SET again (Re: newest kernel

To: Joe deBlaquiere <jadb@redhat.com>
Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel
From: Jun Sun <jsun@mvista.com>
Date: Wed, 23 May 2001 11:41:57 -0700
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>, Florian Lohoff <flo@rfc822.org>, ralf@oss.sgi.com, Pete Popov <ppopov@mvista.com>, George Gensure <werkt@csh.rit.edu>, linux-mips@oss.sgi.com
References: <Pine.GSO.3.96.1010523152429.5196A-100000@delta.ds2.pg.gda.pl> <3B0BF7F8.3050306@redhat.com>
Sender: owner-linux-mips@oss.sgi.com
Joe deBlaquiere wrote:
> 
 >  Please don't.  The emulation is an overkill here and the overhead is
> > painful for ISA I systems, which are usually not the fastest ones.  This
> > has already been discussed here.
> >
> 
> There's overhead to sysmips also, so neither one is going to give
> stunning performance. All out performance isn't likely an issue on one
> of these systems anyways.
> 

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.

> >  If you want to go for speed and use ll/sc on an ISA II+ system, then
> > compile glibc for ISA II or better.  It will never call sysmips() then.
> 
>         The problem here is that now I have mips, mipsel, and mipselnollsc
> configurations of the cross-tools, the c library and the binary
> applications. It's one extra configuration to maintain.
>

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. :-)

Jun

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