Re: Wierd context-switching issue on Xeon - Mailing list pgsql-performance

From Tom Lane
Subject Re: Wierd context-switching issue on Xeon
Date
Msg-id 14264.1082573491@sss.pgh.pa.us
Whole thread Raw
In response to Re: Wierd context-switching issue on Xeon  (Paul Tuckfield <paul@tuckfield.com>)
Responses Re: Wierd context-switching issue on Xeon  (Kenneth Marshall <ktm@it.is.rice.edu>)
List pgsql-performance
Paul Tuckfield <paul@tuckfield.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

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: slow seqscan
Next
From: "Matthew T. O'Connor"
Date:
Subject: Re: MySQL vs PG TPC-H benchmarks