Re: Spinlocks, yet again: analysis and proposed patches - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Spinlocks, yet again: analysis and proposed patches
Date
Msg-id 26652.1126844297@sss.pgh.pa.us
Whole thread Raw
In response to Re: Spinlocks, yet again: analysis and proposed patches  (Gregory Maxwell <gmaxwell@gmail.com>)
Responses Re: Spinlocks, yet again: analysis and proposed patches
Re: Spinlocks, yet again: analysis and proposed patches
List pgsql-hackers
Gregory Maxwell <gmaxwell@gmail.com> writes:
> If I had to guess I might say that the 64byte alignment is removing
> much of the unneeded line bouncing in the the two process case but is
> at the same time creating more risk of bouncing caused by aliasing.

It's an idea ... not sure if it's right or not.

One thing I have noticed both on Xeon HT (2-physical-4-logical) and
on Opteron (4 real processors) is that the 2-process times are
significantly more variable than the 1, 4, or 8-process times: repeating
the measurements shows variance around the 10% level for 2 processes
but only around 1% for the others.

What I think this means is that the kernel is scheduling the 2 processes
onto 2 processors chosen-at-random, without awareness of whether those
two processors are on the same chip (in the Xeon case) or have closer
NUMA affinity (in the Opteron case).  The other test cases are all
symmetric and there's no way for the kernel to blow it too badly, but
in the 2-process case it will be very visible whether the kernel
understands the hardware or not.  And the impression I have (which
might be out of date) is that current Linux kernel releases are not
very bright about these things.

How does that tie into the point at hand about different results for
64-byte vs 32-byte LWLocks?  Not sure, but I feel it's related somehow.

Anyway, it'd be interesting to get some test results for these things
on SMP machines running non-Linux kernels.  Also, we ought to be more
rigorous about reporting exactly which kernel we are using for any
particular test.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Gregory Maxwell
Date:
Subject: Re: Spinlocks, yet again: analysis and proposed patches
Next
From: Raghavendra Reddy
Date:
Subject: Request to clarify on sql_numeric datatype