Re: Add spin_delay() implementation for Arm in s_lock.h

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

In response to

Responses

Browse pgsql-hackers by date

  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