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.

Chris <list(at)1006(dot)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(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Chris <list(at)1006(dot)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(at)mit(dot)edu> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
> > Chris <list(at)1006(dot)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(at)gmx(dot)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(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Greg Stark <gsstark(at)mit(dot)edu> writes:
> > Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)mit(dot)edu> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

> > 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.