Re: Further XLogInsert scaling tweaking

On 03.09.2013 16:22, Merlin Moncure wrote:
> On Mon, Sep 2, 2013 at 10:32 PM, Bruce Momjian<bruce(at)momjian(dot)us> wrote:
>> On Mon, Sep 2, 2013 at 10:14:03AM +0300, Heikki Linnakangas wrote:
>>> diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
>>> index 39c58d0..28e62ea 100644
>>> --- a/src/backend/access/transam/xlog.c
>>> +++ b/src/backend/access/transam/xlog.c
>>> @@ -428,8 +428,14 @@ typedef struct XLogCtlInsert
>>> uint64 CurrBytePos;
>>> uint64 PrevBytePos;
>>>
>>> - /* insertion slots, see above for details */
>>> - XLogInsertSlotPadded *insertSlots;
>>> + /*
>>> + * Make sure the above heavily-contended spinlock and byte positions are
>>> + * on their own cache line. In particular, the RedoRecPtr and full page
>>> + * write variables below should be on a different cache line. They are
>>> + * read on every WAL insertion, but updated rarely, and we don't want
>>> + * those reads to steal the cache line containing Curr/PrevBytePos.
>>> + */
>>> + char pad[128];
>>
>> Do we adjust for cache line lengths anywhere else? PGPROC? Should it
>> be a global define?
>
> +1 -- that is, I think it should be.

Ok, committed that way. No, we adjust for cache line lengths anywhere
else. As Alvaro noted, LWLocks are padded, but that's just to keep them
from crossing cache line boundaries, not to keep two lwlocks on separate
cache lines.

Thanks!

- Heikki