Re: Add spin_delay() implementation for Arm in s_lock.h - Mailing list pgsql-hackers

From Blake, Geoff
Subject Re: Add spin_delay() implementation for Arm in s_lock.h
Date
Msg-id C5051A5C-2851-49CC-B663-E7D00BF3E363@amazon.com
Whole thread Raw
In response to Re: Add spin_delay() implementation for Arm in s_lock.h  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Thanks for all the help Tom!

On 4/6/22, 6:07 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:

    CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you
canconfirm the sender and know the content is safe.
 



    "Blake, Geoff" <blakgeof@amazon.com> writes:
    > Hi Tom, Andres,
    > Any additional feedback for this patch?

    I did some more research and testing:

    * Using a Mac with the M1 Pro chip (marginally beefier than the M1
    I was testing on before), I think I can see some benefit in the
    test case I proposed upthread.  It's marginal though.

    * On a Raspberry Pi 3B+, there's no outside-the-noise difference.

    * ISB doesn't exist in pre-V7 ARM, so it seems prudent to restrict
    the patch to ARM64.  I doubt any flavor of ARM32 would be able to
    benefit anyway.  (Googling finds that MariaDB made this same
    choice not long ago [1].)

    So what we've got is that there seems to be benefit at high
    core counts, and it at least doesn't hurt at lower ones.
    That's good enough for me, so pushed.

                            regards, tom lane

    [1] https://jira.mariadb.org/browse/MDEV-25807


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] Add native windows on arm64 support
Next
From: Frédéric Yhuel
Date:
Subject: Re: REINDEX blocks virtually any queries but some prepared queries.