Re: solaris build problem with Sun compilers

[Alan Stange <stange(at)rentec(dot)com>]

Tom Lane wrote:
> Alan Stange <stange(at)rentec(dot)com> writes:
> > Hmmm.   I've just been looking at the last snapshot of the HEAD and 
> > s_lock.h is still using an ldstub instruction instead of a cas for the 
> > inlined tas() function when gcc is being used.   Having a cas 
> > instruction here would probably be an improvement too, right?
>
> [ shrug... ]  The person who submitted the solaris_sparc.s change failed
> to provide any evidence that it was anything but cosmetic, so I didn't
> worry about changing the equivalent gcc code.  If there's actually a
> performance win, please cite chapter and verse.  Also, shouldn't we be
> worrying about breaking older Sparc chips?  Does CAS go all the way
> back?

Well, in principle the cas variant is better as fewer memory writes 
occur.  I'm unable to cite chapter and verse on this detail, but it is 
"better".

I'm fairly sure CAS was included in the v9 instruction set.  I was 
actually surprised to see that you had allowed it in just for this 
reason.  I'm fairly sure this will break any program that needs to link 
against the postgresql libs using a "v8" 32 bit version.

Either way, my original observation is that you ought to have the same 
thing in either location.  I'd leave the ldstub version (minus the 
useless compare and assignment instructions) until you're sure everyone 
is running v8plusb or v9 binaries.


Not that it matters here and now, but Solaris 10 includes atomic_ops in 
libc which are probably all inlined when using the Sun compiler.  It's 
just what you want here and would hide most of these details.  I believe 
these were also added in a Solaris 9 update.
See "man atomic_ops" for details.



> > Finally, I noticed that pg_sleep is calling select() for a sleep.  On 
> > Solaris, this is a fairly expensive way to get off the run queue 
> > compared to just calling nanosleep().   How often do backends go to 
> > sleep here under "typical" workloads?
>
> If you actually reach that syscall you're screwed performance-wise
> anyhow.  I'm disinclined to mess with OS-specific variants of the
> delay logic.

Not a problem.  I was just poking around and asking questions.

-- Alan