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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-performance by date

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