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 1jqGUn-0004hs-Tf for pgsql-hackers@arkaria.postgresql.org; Tue, 30 Jun 2020 13:40:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jqGUm-0006Ay-QI for pgsql-hackers@arkaria.postgresql.org; Tue, 30 Jun 2020 13:40:20 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jqGUm-0006Ar-JI for pgsql-hackers@lists.postgresql.org; Tue, 30 Jun 2020 13:40:20 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jqGUf-0005nr-U4 for pgsql-hackers@postgresql.org; Tue, 30 Jun 2020 13:40:19 +0000 Received: from hnk.local (p2604028-ipngn12401funabasi.chiba.ocn.ne.jp [180.1.110.28]) by oss.nttdata.com (Postfix) with ESMTPSA id 966326029E; Tue, 30 Jun 2020 22:40:10 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.102.3 at oss.nttdata.com Subject: Re: track_planning causing performance regression To: Ants Aasma Cc: Julien Rouhaud , "Tharakan, Robins" , "pgsql-hackers@postgresql.org" References: <2895b53b033c47ccb22972b589050dd9@EX13D05UWC001.ant.amazon.com> <5725cc95-6aea-d3a8-6ea5-36acf780a55d@oss.nttdata.com> From: Fujii Masao Message-ID: Date: Tue, 30 Jun 2020 22:40:09 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020/06/30 20:30, Ants Aasma wrote: > On Tue, 30 Jun 2020 at 08:43, Fujii Masao > wrote: > > > The problem looks to be that spinlocks are terrible with overloaded CPU and a contended spinlock. A process holding the spinlock might easily get scheduled out leading to excessive spinning by everybody. I think a simple thing to try would be to replace the spinlock with LWLock. > > Yes. Attached is the POC patch that replaces per-counter spinlock with LWLock. > > > Great. I think this is the one that should get considered for testing. > > > I did a prototype patch that replaces spinlocks with futexes, but was not able to find a workload where it mattered. > > I'm not familiar with futex, but could you tell me why you used futex instead > of LWLock that we already have? Is futex portable? > > > Futex is a Linux kernel call that allows to build a lock that has uncontended cases work fully in user space almost exactly like a spinlock, while falling back to syscalls that wait for wakeup in case of contention. It's not portable, but probably something similar could be implemented for other operating systems. I did not pursue this further because it became apparent that every performance critical spinlock had already been removed. > > To be clear, I am not advocating for this patch to get included. I just had the patch immediately available and it could have confirmed that using a better lock fixes things. Understood. Thanks for the explanation! Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION