Skip site navigation (1) Skip section navigation (2)

Re: Wierd context-switching issue on Xeon patch for 7.4.1

From: Dave Cramer <pg(at)fastcrypt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 03:06:41
Message-ID: 1082603201.1556.272.camel@localhost.localdomain (view raw or flat)
Thread:
Lists: pgsql-performance
Yeah, I did some more testing myself, and actually get better numbers
with increasing spins per delay to 1000, but my suspicion is that it is
highly dependent on finding the right delay for the processor you are
on.

My hypothesis is that if you spin approximately the same or more time
than the average time it takes to get finished with the shared resource
then this should reduce cs.

Certainly more ideas are required here.

Dave 
On Wed, 2004-04-21 at 22:35, Tom Lane wrote:
> 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
> 
> 
> 
> !DSPAM:40872f7e21492906114513!
> 
> 
-- 
Dave Cramer
519 939 0336
ICQ # 14675561


In response to

Responses

pgsql-performance by date

Next:From: Tom LaneDate: 2004-04-22 03:10:43
Subject: Re: Wierd context-switching issue on Xeon
Previous:From: Josh BerkusDate: 2004-04-22 02:53:24
Subject: Re: Wierd context-switching issue on Xeon patch for 7.4.1

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group