I've compiled 8.0 beta 1 on a R5900 V3.1 (a playstation 2) running
Linux (PS2 Linux 1) for portability testing.
...
I'm wondering: would it be hard to fix the assembly spinlock code
for the R5900?
According to the previous port report from Red Hat, the PS2 chip simply
doesn't have
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
According to the previous port report from Red Hat, the PS2 chip simply
doesn't have any user-space TAS instruction, so you're pretty much stuck.
Out of curiosity. If it lacks a tas instruction, is there really any smp
On Tue, 24 Aug 2004, Greg Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Chris [EMAIL PROTECTED] writes:
I've compiled 8.0 beta 1 on a R5900 V3.1 (a playstation 2) running
Linux (PS2 Linux 1) for portability testing.
...
I'm wondering: would it be hard to fix the assembly
Tom Lane wrote:
If that's not worth the trouble, would it be a good idea to have
configure disable spinlocks automagically on unsupported platforms?
It used to do that. We deliberately changed this in 8.0 so that
people would be aware that they were losing performance, and would be
Peter Eisentraut [EMAIL PROTECTED] writes:
Actually, the previous port report for 7.4 already required explicit
disabling:
needs new config.guess, --disable-spinlocks
Yeah, because *normal* ARM processors have a TAS instruction,
and configure only recognizes that you have an ARM.
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
According to the previous port report from Red Hat, the PS2 chip simply
doesn't have any user-space TAS instruction, so you're pretty much stuck.
Out of curiosity. If it lacks a
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Think harder... one processor != one process...
Well sure, but you don't want a spinlock in that case.
Actually you do, when the normal case is that you don't have to block.
You want it to fall through as quickly as
Think harder... one processor != one process...
Well sure, but you don't want a spinlock in that case.
Actually you do, when the normal case is that you don't have to block.
You want it to fall through as quickly as possible in the success case
(the blocking case is going to suck no
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
I guess it could still save some CPU cycles in the single CPU case,
if you yield() instead of tight loop around TAS in the failure case.
Problem is yield and detecting single CPU is not portable.
Sure, but that's still a spinlock --- you're
Tom Lane wrote:
But yes, a yield primitive would be nice, and so would knowing the
number of CPUs.
I'm planning on submitting a patch shortly that determines the number of
CPUs in the machine and adjusts the spinlock behavior accordingly (there
are various APIs for getting the # of CPUs, like
Neil Conway [EMAIL PROTECTED] writes:
Speaking of improving spinlock behavior, there's a Solaris API that I
think might be worth using: schedctl_start() asks the scheduler to not
pre-empt the current process, and schedctl_stop() cancels the request.
The idea the first extremely short
Tom Lane wrote:
Associating such a thing with spinlocks seems certain to be a dead loss,
as the amount of time we normally hold a spinlock is much less than the
time to make one kernel call, let alone two.
Yeah, I was thinking about this. ISTM the only way that Sun would bother
to provide an API
Neil Conway [EMAIL PROTECTED] writes:
Tom Lane wrote:
On the count-the-number-of-CPUs patch, what sort of coverage are you
expecting to get?
I haven't yet seen a platform that doesn't provide some means to get the
# of CPUs, but I suppose there might be one...
It might be worth exposing
Neil Conway [EMAIL PROTECTED] writes:
Tom Lane wrote:
Associating such a thing with spinlocks seems certain to be a dead loss,
as the amount of time we normally hold a spinlock is much less than the
time to make one kernel call, let alone two.
Yeah, I was thinking about this. ISTM the
Hi,
I've compiled 8.0 beta 1 on a R5900 V3.1 (a playstation 2) running
Linux (PS2 Linux 1) for portability testing.
Here is what make check gave:
Without --disable-spinlocks
compilation *appears* to be fine, but the backends core dumps
on the spinlock assembly in s_lock.c (signal 4 -- illegal
Chris [EMAIL PROTECTED] writes:
I've compiled 8.0 beta 1 on a R5900 V3.1 (a playstation 2) running
Linux (PS2 Linux 1) for portability testing.
...
I'm wondering: would it be hard to fix the assembly spinlock code
for the R5900?
According to the previous port report from Red Hat, the PS2
Tom Lane [EMAIL PROTECTED] writes:
Chris [EMAIL PROTECTED] writes:
I've compiled 8.0 beta 1 on a R5900 V3.1 (a playstation 2) running
Linux (PS2 Linux 1) for portability testing.
...
I'm wondering: would it be hard to fix the assembly spinlock code
for the R5900?
According to the
17 matches
Mail list logo
