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
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 |