From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pg(at)fastcrypt(dot)com |
Cc: | Paul Tuckfield <paul(at)tuckfield(dot)com>, Anjan Dave <adave(at)vantage(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Neil Conway <neilc(at)samurai(dot)com>, Dirk Lutzebäck <lutzeb(at)aeccom(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Wierd context-switching issue on Xeon patch for 7.4.1 |
Date: | 2004-04-22 02:35:30 |
Message-ID: | 18322.1082601330@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Dave Cramer <pg(at)fastcrypt(dot)com> writes:
> diff -c -r1.16 s_lock.c
> *** backend/storage/lmgr/s_lock.c 8 Aug 2003 21:42:00 -0000 1.16
> --- backend/storage/lmgr/s_lock.c 21 Apr 2004 20:27:34 -0000
> ***************
> *** 76,82 ****
> * The select() delays are measured in centiseconds (0.01 sec) because 10
> * msec is a common resolution limit at the OS level.
> */
> ! #define SPINS_PER_DELAY 100
> #define NUM_DELAYS 1000
> #define MIN_DELAY_CSEC 1
> #define MAX_DELAY_CSEC 100
> --- 76,82 ----
> * The select() delays are measured in centiseconds (0.01 sec) because 10
> * msec is a common resolution limit at the OS level.
> */
> ! #define SPINS_PER_DELAY 10
> #define NUM_DELAYS 1000
> #define MIN_DELAY_CSEC 1
> #define MAX_DELAY_CSEC 100
As far as I can tell, this does reduce the rate of semop's
significantly, but it does so by bringing the overall processing rate
to a crawl :-(. I see 97% CPU idle time when using this patch.
I believe what is happening is that the select() delay in s_lock.c is
being hit frequently because the spin loop isn't allowed to run long
enough to let the other processor get out of the spinlock.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2004-04-22 02:53:24 | Re: Wierd context-switching issue on Xeon patch for 7.4.1 |
Previous Message | Tom Lane | 2004-04-22 01:45:54 | Re: Wierd context-switching issue on Xeon |