On Fri, Jul 29, 2016 at 2:12 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Jul 28, 2016 at 12:12 AM, Thomas Munro > <thomas.mu...@enterprisedb.com> wrote: >> On Tue, Jul 26, 2016 at 6:00 AM, Andres Freund <and...@anarazel.de> wrote: >>> I think the better fix here would acutally be to get rid of a pointer >>> based list here, and a) replace the queue with integer offsets ... >> >> Here is a prototype of that idea. It replaces that dlist with a >> proclist, a new specialised doubly-linked list for pgprocno values, >> using INVALID_PGPROCNO for termination. It works with proclist_node >> objects inside PGPROC at an arbitrary offset which must be provided >> when you initialise the proclist. > > Aside from the fact that this allows LWLocks inside DSM segments, > which I definitely want to support, this seems to have the nice > property of reducing the size of an LWLock by 8 bytes. We need to > consider what to do about LWLOCK_MINIMAL_SIZE. We could (a) decide to > still pad all arrays of LWLocks to 32 bytes per LWLock so as to reduce > false sharing, and rename this constant not to imply minimality; or > (b) alter the macro definition to allow for 16 bytes as a possible > result.
That version didn't actually make LWLock any smaller, because of the additional offset stored in proclist_head when initialising the list. Here is a new version that requires callers to provide it when accessing the list, bringing sizeof(LWLock) down to 16 on LP64/LLP64 systems. In the spirit of the dlist_container macro, I added macros so you can name the link member rather than providing its offset: proclist_push_tail(&list, procno, lwWaitLink). -- Thomas Munro http://www.enterprisedb.com
lwlocks-in-dsm-v3.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
