From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | stange(at)rentec(dot)com |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-ports(at)postgresql(dot)org |
Subject: | Re: solaris build problem with Sun compilers |
Date: | 2006-05-12 18:10:31 |
Message-ID: | 12675.1147457431@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-ports |
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?
> 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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2006-05-12 18:14:47 | Re: solaris build problem with Sun compilers |
Previous Message | Alan Stange | 2006-05-12 17:43:44 | Re: solaris build problem with Sun compilers |