Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1seKJ5-0064fO-D4 for pgsql-hackers@arkaria.postgresql.org; Wed, 14 Aug 2024 20:09:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1seKJ4-00Ce7d-4r for pgsql-hackers@arkaria.postgresql.org; Wed, 14 Aug 2024 20:09:18 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1seKJ3-00Ce7V-M6 for pgsql-hackers@lists.postgresql.org; Wed, 14 Aug 2024 20:09:17 +0000 Received: from lahtoruutu.iki.fi ([2a0b:5c81:1c1::37]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1seKJ0-004kdA-IL for pgsql-hackers@postgresql.org; Wed, 14 Aug 2024 20:09:16 +0000 Received: from [192.168.1.110] (dsl-hkibng22-54f8db-125.dhcp.inet.fi [84.248.219.125]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: hlinnaka) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 4WkfTv09ktz49PsT; Wed, 14 Aug 2024 23:09:06 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1723666150; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3+ejGmATNn9MaN/hGSaRaUiOt+3+rTkDh28eGLpp9HU=; b=MI4TL/3WVSpXF3YX9zWXaOL3i7chM0vsDjx9+WpU2M9Zu1MAruShJLQK8cjKLk2xMgzn/X xjk6RDfLM8laiBZdO25yZIkvCv02P4L85hGXoEQQoPfy/AmFcbU+HOypAa0EYC/fPrQwgz oH+voYPOop16+QOtHrdaWTnYepWmZx3tpJdRKGnAMuTaIpIdKwojHYj6PzCB413+2GbP15 aIGT1AKfrVYJEkhakcWfEtarinee0OQH/F+w1NcBahqlDZD/LFwWxqQmQjGE4Pvtrp3YR5 UrvgVJhJ/jWkCmGhLrurQK0wrivWBUkP/JSLoJajahqgS2TjJZF1fVyUhJSwrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1723666150; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3+ejGmATNn9MaN/hGSaRaUiOt+3+rTkDh28eGLpp9HU=; b=byxgTVbPfZ3QOe6zUDBd/wuet5A3qqkVBqsh+A56H3wjbxiV3jzoumWfinLSJTkg0OmlaI sr6EQXowNG8vIaMogT0Ml8UlOcbe28GWDLVGQ51cAXcojW+s3ijEF54Kj+0KTh9ewClxmk LMEhGutoyEfE5G2Tj7/7/mB08a1RrRrrFTY7QdFwbRJNryzEtylR6KF7VzDYQ2y4u3OH3q j63DkFLrjiNxOXJpUFWDJt0TfHR4kb//CWckxzSqEfA8ZwvYDWF54OvB4jfr4BZ3IZxTWt c3z4ORUUdnKMzakH0zDD7fdQ83N+ICh9OduIN7EL95ob1B9vkX5/WTC838D/wQ== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=hlinnaka smtp.mailfrom=hlinnaka@iki.fi ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1723666150; a=rsa-sha256; cv=none; b=cL4uD1f6xN5LTRj1C5Uq6aLR3NqrZuv1xHqhX7pK5KucaLT5a9kBzZ0F3Jz4C5Mgj0eLn/ IdBzfBMLGle3GD+OK3wEcy8wB4oR5gNtN3bi5Sq9Yvs+xNsjRupbY0Y/OTQwcbLi4KrJw4 bPW0/HDSVQ6d2+RGUMFjGIgAp+imot7PKlxa/12lphparYKHfadk16iBtvdGtDLIaYXESs DjMwicylnqL/Rw45/2EDkDcGPryvKwg9CV9sEjRTLA9V43xWdF7FAvLvphk+zO7xpXCDwd cP3b2a0lAkLHSkdY/mRfTOxaH6WucSUFpDYPy3d8OVNlezunyKJfdtHwvZjvSg== Message-ID: <40da8288-05fd-4028-adab-81db2092ba8c@iki.fi> Date: Wed, 14 Aug 2024 23:09:06 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: AIX support To: Srirama Kucherlapati , Heikki Linnakangas , Laurenz Albe , Bruce Momjian Cc: Peter Eisentraut , Alvaro Herrera , "pgsql-hackers@postgresql.org" , Noah Misch , Michael Paquier , Andres Freund , Tom Lane , Thomas Munro , "tvk1271@gmail.com" , "postgres-ibm-aix@wwpdl.vnet.ibm.com" References: <698dd3efec644b5c0dd6220d73033f8153ae2fde.camel@cybertec.at> <95a44be0-b2f8-464a-8984-771d892b1cac@iki.fi> Content-Language: en-US From: Heikki Linnakangas In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 14/08/2024 18:22, Srirama Kucherlapati wrote: > Hi Heikki, > > I have attached the merged patch with all the changes, the earlier patch was > > just only the changes specific to older review comments. > >     > I'm sorry, I don't understand what you're saying here. Do you > mean that >     > we don't need to do anything here, and the code we have in > s_lock.h in >     > 'master' now will work fine on AIX? Or do we need to (re-)do some >     > changes to support AIX again? If we only support GCC, can we use the >     > __sync_lock_test_and_set() builtin instead? > > Here we need these changes for ppc. These changes are not for > enabling the AIX support, but this is implementing “Enhanced PowerPC > Architecture”. This routine is more of compare_and_increment, which > is different from GCC __sync_lock_test_and_set(). Also I tried to > write a sample function to check the assemble generated by > __sync_lock_test_and_set(), which turned out to be different set of > assemble code. I still don't understand. We have Linux powerpc systems running happily in the buildfarm. They are happy with the current spinlock implementation. Why is this needed? What happens without it? How is this different from __sync_lock_test_and_set()? Is the __sync_lock_test_and_set() on that platform broken, less efficient, or just different but equally good? >     > > +#define TAS(lock)                      _check_lock((slock_t *) > (lock), >     > > 0, 1) >     > > >     >>  +#define S_UNLOCK(lock)         _clear_lock((slock_t *) (lock), 0) >     >> >     > > The above changes are specific to AIX kernel and it operates on > fixed >     > > kernel memory. This is more like a compare_and_swap > functionality with >     > > sync capability. For all the assemble code I think it would be > better to >     > > use the IBM Power specific asm code to gain additional performance. > >     > You mean we don't need the above? Ok, good. > > I mean this part of the code is needed as this is specific to AIX > kernel memory operation which is different from > __sync_lock_test_and_set(). How is it different from __sync_lock_test_and_set()? Why is it needed? What is AIX kernel memory operation? > I would like to mention that the changes made in > src/include/storage/s_lock.h > > are pretty much required and need to be operated in assemble specific to IBM > Power architecture. Note that your patch both modifies the existing powerpc implementation, and introduces a new AIX-specific one. They cannot *both* be required, because only one of them will ever be compiled on a given platform. Which is it? Or are you trying to make this work on multiple different CPUs on AIX, so that different implementation gets chosen on different CPUs? Is the mkldexport stuff still needed on modern AIX? Or was it specific to XLC and never needed on GCC? How do other products do that? On a general note: it's your responsibility to explain all the changes in a way that others will understand and can verify. It is especially important for something critical and platform-specific like spinlocks, because others don't have easy access to the hardware to test these things independently. I also want to remind you that from the Postgres community point of view, you are introducing support for a new platform, AIX, not merely resurrecting the old stuff. Every change needs to be justified anew. -- Heikki Linnakangas Neon (https://neon.tech)