8.0 beta 1 on linux-mipsel R5900
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
instruction) on first run.
With --disable-spinlocks
all is well except the two floating point tests float4 and float8
out of 96 tests fail. This is likely due to the R5900 not being
fully IEEE-compliant(?) (regression.diffs attached).
--
I'm wondering: would it be hard to fix the assembly spinlock code
for the R5900?
If that's not worth the trouble, would it be a good idea to have
configure disable spinlocks automagically on unsupported platforms?
Or is it to hard to autodetect this?
Bye, Chris.
PS: I've compiled using gcc 2.95.2 and with CFLAGS -O0 -g.
Attachments:
regression.diffstext/x-patch; charset=ISO-8859-15; name=regression.diffsDownload
*** ./expected/float4.out Fri Mar 12 01:25:40 2004
--- ./results/float4.out Tue Aug 24 02:18:42 2004
***************
*** 33,67 ****
ERROR: invalid input syntax for type real: "123 5"
-- special inputs
SELECT 'NaN'::float4;
! float4
! --------
! NaN
! (1 row)
!
SELECT 'nan'::float4;
! float4
! --------
! NaN
! (1 row)
!
SELECT ' NAN '::float4;
! float4
! --------
! NaN
! (1 row)
!
SELECT 'infinity'::float4;
! float4
! ----------
! Infinity
! (1 row)
!
SELECT ' -INFINiTY '::float4;
! float4
! -----------
! -Infinity
! (1 row)
!
-- bad special inputs
SELECT 'N A N'::float4;
ERROR: invalid input syntax for type real: "N A N"
--- 33,47 ----
ERROR: invalid input syntax for type real: "123 5"
-- special inputs
SELECT 'NaN'::float4;
! ERROR: type "real" value out of range: overflow
SELECT 'nan'::float4;
! ERROR: type "real" value out of range: overflow
SELECT ' NAN '::float4;
! ERROR: type "real" value out of range: overflow
SELECT 'infinity'::float4;
! ERROR: invalid input syntax for type real: "infinity"
SELECT ' -INFINiTY '::float4;
! ERROR: invalid input syntax for type real: " -INFINiTY "
-- bad special inputs
SELECT 'N A N'::float4;
ERROR: invalid input syntax for type real: "N A N"
***************
*** 70,88 ****
SELECT ' INFINITY x'::float4;
ERROR: invalid input syntax for type real: " INFINITY x"
SELECT 'Infinity'::float4 + 100.0;
! ERROR: type "double precision" value out of range: overflow
SELECT 'Infinity'::float4 / 'Infinity'::float4;
! ?column?
! ----------
! NaN
! (1 row)
!
SELECT 'nan'::float4 / 'nan'::float4;
! ?column?
! ----------
! NaN
! (1 row)
!
SELECT '' AS five, FLOAT4_TBL.*;
five | f1
------+-------------
--- 50,60 ----
SELECT ' INFINITY x'::float4;
ERROR: invalid input syntax for type real: " INFINITY x"
SELECT 'Infinity'::float4 + 100.0;
! ERROR: invalid input syntax for type real: "Infinity"
SELECT 'Infinity'::float4 / 'Infinity'::float4;
! ERROR: invalid input syntax for type real: "Infinity"
SELECT 'nan'::float4 / 'nan'::float4;
! ERROR: type "real" value out of range: overflow
SELECT '' AS five, FLOAT4_TBL.*;
five | f1
------+-------------
======================================================================
*** ./expected/float8.out Fri Apr 23 22:32:20 2004
--- ./results/float8.out Tue Aug 24 02:18:42 2004
***************
*** 33,67 ****
ERROR: invalid input syntax for type double precision: "123 5"
-- special inputs
SELECT 'NaN'::float8;
! float8
! --------
! NaN
! (1 row)
!
SELECT 'nan'::float8;
! float8
! --------
! NaN
! (1 row)
!
SELECT ' NAN '::float8;
! float8
! --------
! NaN
! (1 row)
!
SELECT 'infinity'::float8;
! float8
! ----------
! Infinity
! (1 row)
!
SELECT ' -INFINiTY '::float8;
! float8
! -----------
! -Infinity
! (1 row)
!
-- bad special inputs
SELECT 'N A N'::float8;
ERROR: invalid input syntax for type double precision: "N A N"
--- 33,47 ----
ERROR: invalid input syntax for type double precision: "123 5"
-- special inputs
SELECT 'NaN'::float8;
! ERROR: type "double precision" value out of range: overflow
SELECT 'nan'::float8;
! ERROR: type "double precision" value out of range: overflow
SELECT ' NAN '::float8;
! ERROR: type "double precision" value out of range: overflow
SELECT 'infinity'::float8;
! ERROR: invalid input syntax for type double precision: "infinity"
SELECT ' -INFINiTY '::float8;
! ERROR: invalid input syntax for type double precision: " -INFINiTY "
-- bad special inputs
SELECT 'N A N'::float8;
ERROR: invalid input syntax for type double precision: "N A N"
***************
*** 70,88 ****
SELECT ' INFINITY x'::float8;
ERROR: invalid input syntax for type double precision: " INFINITY x"
SELECT 'Infinity'::float8 + 100.0;
! ERROR: type "double precision" value out of range: overflow
SELECT 'Infinity'::float8 / 'Infinity'::float8;
! ?column?
! ----------
! NaN
! (1 row)
!
SELECT 'nan'::float8 / 'nan'::float8;
! ?column?
! ----------
! NaN
! (1 row)
!
SELECT '' AS five, FLOAT8_TBL.*;
five | f1
------+----------------------
--- 50,60 ----
SELECT ' INFINITY x'::float8;
ERROR: invalid input syntax for type double precision: " INFINITY x"
SELECT 'Infinity'::float8 + 100.0;
! ERROR: invalid input syntax for type double precision: "Infinity"
SELECT 'Infinity'::float8 / 'Infinity'::float8;
! ERROR: invalid input syntax for type double precision: "Infinity"
SELECT 'nan'::float8 / 'nan'::float8;
! ERROR: type "double precision" value out of range: overflow
SELECT '' AS five, FLOAT8_TBL.*;
five | f1
------+----------------------
======================================================================
Chris <list@1006.org> 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 chip simply
doesn't have any user-space TAS instruction, so you're pretty much stuck.
If you can find something that works, let us know.
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 motivated
to look into possible solutions.
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes:
Chris <list@1006.org> 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 chip simply
doesn't have any user-space TAS instruction, so you're pretty much stuck.
If you can find something that works, let us know.
Out of curiosity. If it lacks a tas instruction, is there really any smp
implementation that runs on it? Why would postgres want spinlocks at all with
only one processor?
--
greg
Greg Stark <gsstark@mit.edu> writes:
Tom Lane <tgl@sss.pgh.pa.us> 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
implementation that runs on it?
My recollection is that it has TAS capability but the designers made it
a privileged instruction (in a fit of brain death :-()
Why would postgres want spinlocks at all with only one processor?
Think harder... one processor != one process...
regards, tom lane
On Tue, 24 Aug 2004, Greg Stark wrote:
Tom Lane <tgl@sss.pgh.pa.us> writes:
Chris <list@1006.org> 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 chip simply
doesn't have any user-space TAS instruction, so you're pretty much stuck.
If you can find something that works, let us know.Out of curiosity. If it lacks a tas instruction, is there really any smp
implementation that runs on it? Why would postgres want spinlocks at all with
only one processor?
Errm. Even if we have only one CPU it doesn't mean instructions which
read/write to shared resources in a *multiprocess* environment will be
serialized in the way we want. In fact, its highly unlikely that they
will. If you want to test, make TAS() a noop and see how quickly
things are corrupted in shared memory :-)
Gavin
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
motivated to look into possible solutions.
Actually, the previous port report for 7.4 already required explicit
disabling:
needs new config.guess, --disable-spinlocks
(We fixed that first point anyway.)
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Peter Eisentraut <peter_e@gmx.net> 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.
Apparently Sony bought the 10-cents-off-special without TAS ...
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes:
Greg Stark <gsstark@mit.edu> writes:
Tom Lane <tgl@sss.pgh.pa.us> 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
implementation that runs on it?
Ah, that would be poor.
My recollection is that it has TAS capability but the designers made it
a privileged instruction (in a fit of brain death :-()Why would postgres want spinlocks at all with only one processor?
Think harder... one processor != one process...
Well sure, but you don't want a spinlock in that case. You may as well yield
immediately rather than spinning waiting for the inevitable context switch.
Your tas is never going to succeed until the context switch happens anyways.
But I think I'm on the wrong track. Without tas, you don't even get to handle
the common case of an uncontested lock without some sort of kernel call to
block context switches, so you still get a performance hit.
--
greg
Greg Stark <gsstark@mit.edu> writes:
Tom Lane <tgl@sss.pgh.pa.us> 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 possible in the success case
(the blocking case is going to suck no matter what). Given the present
set of available/portable technologies, spinlocks win.
If you've got a better alternative, educate us ...
regards, tom lane
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 matter what). Given the present
set of available/portable technologies, spinlocks win.
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.
Andreas
Import Notes
Resolved by subject fallback
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> 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 just tuning the backoff
behavior for local conditions.
On some architectures (Alpha at least) the TAS instruction can "fail"
even though the lock is free, if an interrupt happens to get in the way.
So I'd be inclined to loop a few times even on a single-CPU machine.
But yes, a yield primitive would be nice, and so would knowing the
number of CPUs.
regards, tom lane
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 sysctl() on many Unixen
and GetSystemInfo() on Win32).
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 periods of time that we're holding a
spinlock, we don't want to get preempted, since if the process was
allowed to run for just a little bit longer it would probably give up
the spinlock. The docs are here:
http://docs.sun.com/db/doc/816-3324/6m9k4vdu1?a=view
-Neil
Neil Conway <neilc@samurai.com> 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 periods of time that we're holding a
spinlock, we don't want to get preempted, since if the process was
allowed to run for just a little bit longer it would probably give up
the spinlock.
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.
Associating it with LWLocks is slightly more plausible. There are some
LWLocks that are held for lengths of time that would make it reasonable
to do this (but not all of them are used that way, so some thought is
still needed).
On the count-the-number-of-CPUs patch, what sort of coverage are you
expecting to get? If we could be certain that all SMP-capable platforms
are covered, then we could default to assuming 1 CPU on platforms that
don't have any of those APIs, which would be a win.
regards, tom lane
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 like this is if it had significantly less overhead
than a standard system call. Anyway, I'll take a closer look.
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...
-Neil
Neil Conway <neilc@samurai.com> 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 the CPU count as a GUC variable. This would
* make it easy to check on the results of the counting patch;
* make it easy to override the patch, if it's wrong on some platform;
* make it easy to experiment to see whether the spinlock behavioral
change actually matters ;-)
But this may be overkill.
regards, tom lane
Neil Conway <neilc@samurai.com> 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 only way that Sun would bother to
provide an API like this is if it had significantly less overhead than a
standard system call. Anyway, I'll take a closer look.
There are ways they could have done this too. It doesn't really need a syscall
since the kernel doesn't need the information until it tries to do a context
switch. The function could merely place the information in a shared memory
page for the kernel to consult when the timer interrupt goes off.
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...
As Tom mentions, it would be nice to be able to override it. One reason I can
think of is if you're on a machine with many processors but have used admin
tools to bind postgres to just a subset of the processors or even just a
single processor. You would want postgres to behave as if it's a machine with
only those processors.
--
greg
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 any user-space TAS instruction, so you're pretty much stuck.
If you can find something that works, let us know.
I've asked about this issue on the ps2 linux forums and somebody
came up with this document:
http://lc.linux.or.jp/lc2001/papers/tas-ps2-paper.pdf
See also this releated thread on the linux-mips list:
http://www.linux-mips.org/archives/linux-mips/2002-01/msg00278.html
I'm not fluent in Japanese or MIPS assembly, so I won't comment
on these. Just posting the links :)
Bye, Chris.