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

From Zeugswetter Andreas SB SD
Subject Re: 8.0 beta 1 on linux-mipsel R5900
Date
Msg-id 46C15C39FEB2C44BA555E356FBCD6FA40184D179@m0114.s-mxs.net
Whole thread Raw
In response to 8.0 beta 1 on linux-mipsel R5900  (Chris <list@1006.org>)
Responses Re: 8.0 beta 1 on linux-mipsel R5900  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> >> 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


pgsql-hackers by date:

Previous
From: Richard Huxton
Date:
Subject: Re: [COMMITTERS] pgsql-server: Rearrange pg_subtrans handling
Next
From: "Zeugswetter Andreas SB SD"
Date:
Subject: Re: PITR: XLog File compression on Archive