Re: MIPS_ATOMIC_SET again (Re: newest kernel

[Joe deBlaquiere <jadb@redhat.com>]

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