[Top] [All Lists]

Re: MIPS_ATOMIC_SET again (Re: newest kernel

To: Florian Lohoff <>
Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel
From: Joe deBlaquiere <>
Date: Wed, 23 May 2001 15:04:41 -0500
Cc: Jun Sun <>, "Maciej W. Rozycki" <>,, Pete Popov <>, George Gensure <>,, "Kevin D. Kissell" <>
References: <> <> <> <> <>
User-agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; 0.8.1) Gecko/20010422

Florian Lohoff wrote:

On Wed, May 23, 2001 at 08:54:12PM +0200, Florian Lohoff wrote:

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.

But again - I tried to run this discussion again and again - As long
as there is no code to use there is no point in taking a discussion.
I needed a working sysmips for debian as we compile the glibc with
sysmips (performance penalty but for now works everywhere) thus
i fixed the sysmips.

I have to agree with the pragmatism first, philosophy second approach. If it is 
beautiful but doesn't work it dosn't help anyone.

The thing I don't understand is how glibc is going to cleanly decide at runtime which code to use. It's relatively easy to do something like that in the kernel, but I can't come up with an elegant solution to make such a choice at runtime in glibc.

Assuming that we're moving forward (as Kevin points out) the percentage of systems without ll/sc is going down. While these systems don't have much CPU power to spare, we should make the baseline implementation have ll/sc emulation. If somebody wants to make a MIPS I optimized glibc, then that's fine, but allowing the 'standard' MIPSII glibc to work on all systems simplifies life ( mine at least ;) ).

Joe deBlaquiere
Red Hat, Inc.
307 Wynn Drive
Huntsville AL, 35805
voice : (256)-704-9200
fax   : (256)-837-3839

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