rmurray@debian.org writes:
> On Tue, Jun 11, 2002 at 02:05:34PM -0400, Tom Lane wrote:
>> The s_lock change is in current sources, but it concerns me because it
>> seems it could break other mips-based platforms (ie, pre-mips2). I'd
> The Linux kernel will emulate ll/sc on mips1 platforms. If other kernels
> won't/don't do this, then this should be made Linux/mips specific.
That's exactly the answer I did *not* want to hear. The entire reason
why we bother with TAS assembly coding is to avoid a trip to the kernel
for low-level synchronization operations. If the existing s_lock coding
incurs a protection fault and kernel emulation on MIPS1 machines, then
it's worse than useless.
What I'm currently thinking is that we should undo the s_lock change and
add appropriate coding into the template files for all MIPS-capable
platforms to select "-mips2" where appropriate. Thoughts? It's not
real clear to me what the difference is that is actually created by
either the assembler directive or the compiler flag; can someone give
exact details?
> Prebuilt binaries provided by distributions like Debian often build for the
> lowest common ISA that will work on all of the available hardware, so every
> binary in the distribution is built for mips1, with the addition of ll/sc,
> being emulated by the kernel, or done in hardware (if available)
That is probably not going to be acceptable from a performance point of
view. Note the comment in s_lock.h about 40% penalty for
non-hardware-based spinlocks; if anything the number is probably worse
today.
regards, tom lane