Re: spin_delay() for ARM - Mailing list pgsql-hackers

From Robert Haas
Subject Re: spin_delay() for ARM
Date
Msg-id CA+TgmobRAH82_Ot44gE==PGQgzejG0escF-4uqCK2W5Qdfmn2Q@mail.gmail.com
Whole thread Raw
In response to Re: spin_delay() for ARM  (Amit Khandekar <amitdkhan.pg@gmail.com>)
List pgsql-hackers
On Thu, Apr 16, 2020 at 3:18 AM Amit Khandekar <amitdkhan.pg@gmail.com> wrote:
> Not relevant to the PAUSE stuff .... Note that when the parallel
> clients reach from 24 to 32 (which equals the machine CPUs), the TPS
> shoots from 454189 to 1097592 which is more than double speed gain
> with just a 30% increase in parallel sessions.

I've seen stuff like this too. For instance, check out the graph from
this 2012 blog post:

http://rhaas.blogspot.com/2012/04/did-i-say-32-cores-how-about-64.html

You can see that the performance growth is basically on a straight
line up to about 16 cores, but then it kinks downward until about 28,
after which it kinks sharply upward until about 36 cores.

I think this has something to do with the process scheduling behavior
of Linux, because I vaguely recall some discussion where somebody did
benchmarking on the same hardware on both Linux and one of the BSD
systems, and the effect didn't appear on BSD. They had other problems,
like a huge drop-off at higher core counts, but they didn't have that
effect.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Possible cache reference leak by removeExtObjInitPriv
Next
From: Robert Haas
Date:
Subject: Re: Should we add xid_current() or a int8->xid cast?