Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\))
Subject: Re: use a non-locking initial test in TAS_SPIN on AArch64
From: Jingtang Zhang <mrdrivingduck@gmail.com>
In-Reply-To: <CAPsk3_Bx5PhS9A+NH7SO2K-bwrZS7q4i-WTy1Bf98j0CAEqa=g@mail.gmail.com>
Date: Wed, 15 Jan 2025 19:50:38 +0800
Cc: pgsql-hackers@lists.postgresql.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <74D40BAB-C23D-497E-8153-67B543663182@gmail.com>
References: <ZxgDEb_VpWyNZKB_@nathan>
 <CAPsk3_Bx5PhS9A+NH7SO2K-bwrZS7q4i-WTy1Bf98j0CAEqa=g@mail.gmail.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Archived-At: <https://www.postgresql.org/message-id/74D40BAB-C23D-497E-8153-67B543663182%40gmail.com>
Precedence: bulk

Hi, Nathan.

I just realized that I almost forgot about this thread :)

> The result looks great, but the discussion in [0] shows that the =
result may
> vary among different ARM chips. Could you provide the chip model of =
this
> test? So that we can do a cross validation of this patch. Not sure if =
compiler
> version is necessary too. I'm willing to test it on Alibaba Cloud =
Yitian 710
> if I have time.

I did some benchmark on Yitian 710.

On c8y.16xlarge (64 cores):

Without the patch:
  80.31%  postgres               [.] __aarch64_swp4_acq
   1.77%  postgres               [.] __aarch64_ldadd4_acq_rel
   1.13%  postgres               [.] hash_search_with_hash_value
   0.87%  pg_stat_statements.so  [.] __aarch64_swp4_acq
   0.72%  postgres               [.] perform_spin_delay
   0.44%  postgres               [.] _bt_compare

tps =3D 295272.628421 (including connections establishing)
tps =3D 295335.660323 (excluding connections establishing)

Patched:
   9.94%  postgres               [.] s_lock
   6.07%  postgres               [.] __aarch64_swp4_acq
   5.73%  postgres               [.] hash_search_with_hash_value
   2.81%  postgres               [.] perform_spin_delay
   2.29%  postgres               [.] _bt_compare
   2.15%  postgres               [.] PinBuffer

tps =3D 864519.764125 (including connections establishing)
tps =3D 864638.244443 (excluding connections establishing)


Seems that great performance could be gained if s_lock contention is =
severe.
This may be more likely to happen on bigger machines.

On c8y.2xlarge (8 cores), I failed to make s_lock contended severely, =
and
as a result this patch didn=E2=80=99t bring any difference outside the =
noise.


Regards,
Jingtang