Re: 8.0 beta 1 on linux-mipsel R5900 - Mailing list pgsql-hackers

From Greg Stark
Subject Re: 8.0 beta 1 on linux-mipsel R5900
Date
Msg-id 87zn4l11nb.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: 8.0 beta 1 on linux-mipsel R5900  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: 8.0 beta 1 on linux-mipsel R5900  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: 8.0 beta 1 on linux-mipsel R5900
Next
From: strk
Date:
Subject: Re: returning modified input from C functions