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

Re: Wierd context-switching issue on Xeon

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Paul Tuckfield <paul(at)tuckfield(dot)com>
Cc: pg(at)fastcrypt(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
Date: 2004-04-21 18:51:31
Message-ID: 14264.1082573491@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
Paul Tuckfield <paul(at)tuckfield(dot)com> writes:
> I wonder do the threads stall so badly when pinging cache lines back 
> and forth,  that the kernel sees it as an opportunity to put the 
> process to sleep? or do these worst case misses cause an interrupt?

No; AFAICS the kernel could not even be aware of that behavior.

The context swap storm is happening because of contention at the next
level up (LWLocks rather than spinlocks).  It could be an independent
issue that just happens to be triggered by the same sort of access
pattern.  I put forward a hypothesis that the cache miss storm caused by
the test-and-set ops induces the context swap storm by making the code
more likely to be executing in certain places at certain times ... but
it's only a hypothesis.

Yesterday evening I had pretty well convinced myself that they were
indeed independent issues: profiling on a single-CPU machine was telling
me that the test case I proposed spends over 10% of its time inside
ReadBuffer, which certainly seems like enough to explain a high rate of
contention on the BufMgrLock, without any assumptions about funny
behavior at the hardware level.  However, your report and Dave's suggest
that there really is some linkage.  So I'm still confused.

			regards, tom lane

In response to

Responses

pgsql-performance by date

Next:From: Matthew T. O'ConnorDate: 2004-04-21 18:57:16
Subject: Re: MySQL vs PG TPC-H benchmarks
Previous:From: Tom LaneDate: 2004-04-21 18:20:25
Subject: Re: slow seqscan

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