On Nov 24, 2010, at 5:49 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Jeff Janes <jeff.janes@gmail.com> writes:
>> I've played a bit with hash_search_with_hash_value and found that most
>> of the time is spent on shared hash tables, not private ones. And the
>> time attributed to it for the shared hash tables mostly seems to be
>> due to the time it takes to fight cache lines away from other CPUs. I
>> suspect the same thing is true of LWLockAcquire.
>
> That squares with some behavior I've seen. If you run opannotate
> you often see ridiculously high time percentages attributed to extremely
> trivial C statements. The explanation seems to be that those places are
> where chunks of memory are first touched, and have to be pulled into the
> CPU's cache (and, if in shared memory, pulled away from some other CPU).
Does it hurt that, for example, the BufMappingLocks are consecutive in memory? They appear to be among the more
heavilycontended locks even on my 2-core box.
...Robert
