From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
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 02:39:57 |
Message-ID: | 1271756.1641523197@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
>> I landed on the idea of adding some intentional spinlock
>> contention to src/test/modules/test_shm_mq, which is a prefab test
>> framework for passing data among multiple worker processes. The
>> attached quick-hack patch makes it grab and release a spinlock once
>> per passed message.
> 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%.)
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?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2022-01-07 03:13:42 | Re: Add spin_delay() implementation for Arm in s_lock.h |
Previous Message | Andres Freund | 2022-01-07 02:33:55 | Re: Add spin_delay() implementation for Arm in s_lock.h |