From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Blake, Geoff" <blakgeof(at)amazon(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Add spin_delay() implementation for Arm in s_lock.h |
Date: | 2022-01-07 03:13:42 |
Message-ID: | 20220107031342.ltmzvmhifzjnuz2g@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2022-01-06 21:39:57 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > I wonder if this will show the full set of spinlock contention issues - isn't
> > this only causing contention for one spinlock between two processes?
>
> I don't think so -- the point of using the "pipelined" variant is
> that messages are passing between all N worker processes concurrently.
> (With the proposed test, I see N processes all pinning their CPUs;
> if I use the non-pipelined API, they are busy but nowhere near 100%.)
My understanding of the shm_mq code is that that ends up with N shm_mq
instances, one for each worker. After all:
> * shm_mq.c
> * single-reader, single-writer shared memory message queue
These separate shm_mq instances forward messages in a circle,
"leader"->worker_1->worker_2->...->"leader". So there isn't a single contended
spinlock, but a bunch of different spinlocks, each with at most two backends
accessing it?
> It is just one spinlock, true, but I think the point is to gauge
> what happens with N processes all contending for the same lock.
> We could add some more complexity to use multiple locks, but
> does that really add anything but complexity?
Right, I agree that that's what we shoudl test - it's just no immediately
obvious to me that we are.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-01-07 03:23:38 | Re: Add spin_delay() implementation for Arm in s_lock.h |
Previous Message | Tom Lane | 2022-01-07 02:39:57 | Re: Add spin_delay() implementation for Arm in s_lock.h |