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

Dave Cramer <pg@fastcrypt.com>

From: Dave Cramer <pg@fastcrypt.com>
To: Josh Berkus <josh@agliodbs.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Paul Tuckfield <paul@tuckfield.com>, Anjan Dave <adave@vantage.com>, Neil Conway <neilc@samurai.com>, Dirk Lutzebäck <lutzeb@aeccom.com>, pgsql-performance@postgresql.org
Date: 2004-04-22T03:18:47Z
Lists: pgsql-performance
More data....

On a dual xeon with HTT enabled:

I tried increasing the NUM_SPINS to 1000 and it works better.

NUM_SPINLOCKS	CS	ID	pgbench

100		250K	59%	230 TPS
1000		125K	55%	228 TPS

This is certainly heading in the right direction ? Although it looks
like it is highly dependent on the system you are running on.

--dc--	 



On Wed, 2004-04-21 at 22:53, Josh Berkus wrote:
> Tom,
> 
> > 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.
> 
> Also, I tested it on production data, and it reduces the CSes by about 40%.  
> An improvement, but not a magic bullet.
-- 
Dave Cramer
519 939 0336
ICQ # 14675561