Skip site navigation (1) Skip section navigation (2)

Re: LWLock cache line alignment

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <ktm(at)it(dot)is(dot)rice(dot)edu>
Cc: "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: LWLock cache line alignment
Date: 2005-02-04 01:01:35
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us] wrote
> "Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> >> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us] wrote
> >> I've looked at this before and I think it's a nonstarter;
> >> increasing the
> >> size of a spinlock to 128 bytes is just not reasonable.
> > Well, the performance is unreasonably poor, so its time to
> do something,
> > which might if it is unreasonable for the general case
> would need to be
> > port specific.

> But first lets see some evidence that this actually helps?

Yes, thats what we're planning. Currently just brainstorming ideas for
prototyping, rather than suggesting definitive things to go into the

There are some other suggestions there also coming from our Unisys
friends: some additional Intel tweaks to avoid processor stalls and the
like. Again... I'll show the performance figures first.

> Well, it might be worth allocating a full 128 bytes just for the fixed
> LWLocks (BufMgrLock and friends) and skimping on the per-buffer locks,
> which should be seeing far less contention than the fixed
> locks anyway.

Yes, that seems like a likely future way. Right now we're going to pad
the whole structure, to save prototyping time and because we can on a
test box. Working on this now.

My concern about the per-buffer locks is with the CLog and Subtrans
buffer pools. Because we have 8 buffers for each of those it looks like
they'll all be in a single cache line. That means fine grained locking
is ineffective for those caches. With 1000s of shared_buffers, there's
less problem with cache line contention. Possibly Ken's suggestion of
pseudo-randomising the allocation of locks in LWLockAcquire would reduce
the effect on those smaller buffer pools.

Best Regards, Simon Riggs

In response to

pgsql-hackers by date

Next:From: Jonah H. HarrisDate: 2005-02-04 02:16:13
Subject: Re: Escaping the ARC patent
Previous:From: Simon RiggsDate: 2005-02-04 01:01:34
Subject: Re: Escaping the ARC patent

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group