From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: 8.0 beta 1 on linux-mipsel R5900 |
Date: | 2004-08-24 06:38:32 |
Message-ID: | 87zn4l11nb.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | strk | 2004-08-24 06:50:00 | Re: returning modified input from C functions |
Previous Message | Tom Lane | 2004-08-24 06:27:22 | Re: 8.0 beta 1 on linux-mipsel R5900 |