This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: Always use ll/sc for mips


Ralf Baechle wrote:

On Thu, Jul 04, 2002 at 10:47:41AM +0200, Kevin D. Kissell wrote:


The R5900 kernel for the Playstation 2 does not use system
calls. It uses a memory-mapped pseudo-device hack that
the guys at Sony came up with, which is much faster. We
at MIPS came up with an even faster hack which uses the destruction of a "k" register value, but which requires the branch-likely instruction and thus only workson MIPS II CPUs and above (R39xxx, R4xxx, R5xxx,
but not the classic R3K). See my message
"Re: patches for test-and-set without ll/sc" of January 22.

I consider it to be very important for MIPS/Linux
that the embedded/workstation kernel and libraries
merge with the Playstation 2 "consumer" Linux, and
I don't think that will happen if we try to push the
PS2 people to use something far less efficient than
what they already have. "Entia non sunt multiplicanda praeter necessitatem", as a wise old guy once said,
but could we not consider a MIPS/Linux universe
where R3000 binaries use system calls, non-LL/SC
MIPSII+ binaries use k-register destruction, real,
manly, MIPS binaries use LL/SC instructions, and
where the MIPS/Linux kernel (a) supports an appropriate
system call, (b) makes a contract with userland to destroy k-regs predictably, and (c) contains the
emulation logic for LL/SC? That should give us
full cross-platform binary compatibility, with optimal
performance on each platform when an appropriately
configured set of libraries and tools is installed.

No, Sony's ABI isn't MP proof and will break silently on MP systems.  As
such I can't consider it anything else but a hack.  sysmips(MIPS_ATOMIC_SET,
...) and ll/sc however are MP proof.


sysmips(MIPS_ATOMIC_SET, ...) as it is is not MP-safe. Two processors can set the variable at the same time since no spinlock is used to protect the access.

This is also a problem when I was writing preemptiable kernel patch.

Jun



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]