Re: spin_delay() for ARM

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: spin_delay() for ARM
Date: 2020-04-17 17:24:09
Message-ID: CA+TgmobRAH82_Ot44gE==PGQgzejG0escF-4uqCK2W5Qdfmn2Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 16, 2020 at 3:18 AM Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2020-04-17 17:33:53 Re: Should we add xid_current() or a int8->xid cast?
Previous Message Tom Lane 2020-04-17 17:07:15 Re: Possible cache reference leak by removeExtObjInitPriv