| From: | Alan Stange <stange(at)rentec(dot)com> | 
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
| 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 17:43:44 | 
| Message-ID: | 4464C950.40906@rentec.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-ports | 
Tom Lane wrote:
> Alan Stange <stange(at)rentec(dot)com> writes:
>> I took a look at backend/port/tas/solaris_sparc.s file.  Isn't that code 
>> a bit longer than needed?
> 
> It's already been rewritten in HEAD; uses "cas" now.
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?
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?  Yes, I know this is a somewhat 
crazy question, I'm just trying to get a sense of how "hot" this code 
path is.
Thanks!
-- Alan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-05-12 18:10:31 | Re: solaris build problem with Sun compilers | 
| Previous Message | Tom Lane | 2006-05-12 16:31:41 | Re: solaris build problem with Sun compilers |