Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m5s7k-0007Dp-8L for pgsql-hackers@arkaria.postgresql.org; Tue, 20 Jul 2021 15:57:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m5s7j-0004gk-7c for pgsql-hackers@arkaria.postgresql.org; Tue, 20 Jul 2021 15:57:35 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m5s7h-0004gc-Us for pgsql-hackers@lists.postgresql.org; Tue, 20 Jul 2021 15:57:34 +0000 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m5s7e-0005ut-8B for pgsql-hackers@postgresql.org; Tue, 20 Jul 2021 15:57:33 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 0C6FB3200938; Tue, 20 Jul 2021 11:57:25 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Tue, 20 Jul 2021 11:57:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm2; bh=97j+nrpEzJP5TJL5mi8I/bKqilm CyPQIvQJxsBp87XQ=; b=q2mTDpa6R4RNPhv3i1qxEKVYfVFNMs1RDDBLUzhOhRF hkqdJHM5A0MIyJj24YulragCActFwpv4HeYuLTpeC0LAQ+qdhy6Sb6rW5igadIMs o5Kq7B8e5b89Fam/7iMYmyrpvkw7NdVvbCilnRqqPYBSsS3OOTxq7+ujP8vlMvq+ 1M70lPeN5EeaDrwdu+c/+r4ii+Fq9P7NDkEkcvm6524kGEbInhm4RAUgWnmevQ5D OYo9oocmMc9j1vsM1mbXSwZ8QDOZidaPEyXtXpxgS/1/cuKgVD0wnCIG67j48SMX h2f43582avN2fiissUjcVGGNc+HCHtDbjx8S009Ff7Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=97j+nr pEzJP5TJL5mi8I/bKqilmCyPQIvQJxsBp87XQ=; b=t4WsaIOdnFco45f0fvsF3z vv9BSDDdosDsPyxIU6ibQPQ7CfElLvm3UtZoHd8B2gMo03XpL4dJhx2jQIM6UUUS xiWuL5giYRpAZTcN+1w22K/7o/wBuflUjsgKaz/DQd89i6O12jHVFPwDl8rbE9HM kdG6Qgdwoyd/GiWGq8BuUghmwe20VZSm3d72kxXHg34oKPI47/cARbtLdK4kkNu9 PL7oclKCJSuIGT2f1LquTyRa4/UKClL761BLu4fVjV5yzPAxTLomESViQNgkyy2z UeI3h5NN7GTUMq+5Cvws/otpiXSoC5GZMPHX6WzmeEm3DCr4ajB9UpQa1l7MJeow == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrfedvgdelvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkfhggtggujgesthdtredttddtvdenucfhrhhomheptehnughrvghs ucfhrhgvuhhnugcuoegrnhgurhgvshesrghnrghrrgiivghlrdguvgeqnecuggftrfgrth htvghrnhepudekhfekleeugeevteehleffffejgeelueduleeffeeutdelffeujeffhfeu ffdunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprg hnughrvghssegrnhgrrhgriigvlhdruggv X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 20 Jul 2021 11:57:24 -0400 (EDT) Date: Tue, 20 Jul 2021 08:57:23 -0700 From: Andres Freund To: David Rowley Cc: PostgreSQL Development , Robert Haas , Michael Paquier , Tomas Vondra Subject: Re: Avoid stack frame setup in performance critical routines using tail calls Message-ID: <20210720155723.dau4xqsnfq72uih5@alap3.anarazel.de> References: <20210719195950.gavgs6ujzmjfaiig@alap3.anarazel.de> <20210720061657.bcueir3krgmkt6m5@alap3.anarazel.de> <189e4a79-c477-44e0-b3a2-e242b491948d@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On 2021-07-20 19:37:46 +1200, David Rowley wrote: > On Tue, 20 Jul 2021 at 19:04, Andres Freund wrote: > > > * AllocateSetAlloc.txt > > > * palloc.txt > > > * percent.txt > > > > Huh, that's interesting. You have some control flow enforcement stuff turned on (the endbr64). And it looks like it has a non zero cost (or maybe it's just skid). Did you enable that intentionally? If not, what compiler/version/distro is it? I think at least on GCC that's -fcf-protection=... > > It's ubuntu 21.04 with gcc 10.3 (specifically gcc version 10.3.0 > (Ubuntu 10.3.0-1ubuntu1) > > I've attached the same results from compiling with clang 12 > (12.0.0-3ubuntu1~21.04.1) It looks like the ubuntu folks have changed the default for CET to on. andres@ubuntu2020:~$ echo 'int foo(void) { return 17;}' > test.c && gcc -O2 -c -o test.o test.c && objdump -S test.o test.o: file format elf64-x86-64 Disassembly of section .text: 0000000000000000 : 0: f3 0f 1e fa endbr64 4: b8 11 00 00 00 mov $0x11,%eax 9: c3 retq andres@ubuntu2020:~$ echo 'int foo(void) { return 17;}' > test.c && gcc -O2 -fcf-protection=none -c -o test.o test.c && objdump -S test.o test.o: file format elf64-x86-64 Disassembly of section .text: 0000000000000000 : 0: b8 11 00 00 00 mov $0x11,%eax 5: c3 retq Independent of this patch, it might be worth running a benchmark with the default options, and one with -fcf-protection=none. None of my machines support it... $ cpuid -1|grep CET CET_SS: CET shadow stack = false CET_IBT: CET indirect branch tracking = false XCR0 supported: CET_U state = false XCR0 supported: CET_S state = false Here it adds about 40kB of .text, but I can't measure the CET overhead... Greetings, Andres Freund