From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751589AbcLEONo (ORCPT ); Mon, 5 Dec 2016 09:13:44 -0500 Received: from foss.arm.com ([217.140.101.70]:46600 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751086AbcLEONk (ORCPT ); Mon, 5 Dec 2016 09:13:40 -0500 Date: Mon, 5 Dec 2016 14:13:12 +0000 From: Catalin Marinas To: "Zhangjian (Bamvor)" Cc: Maxim Kuvyrkov , linux-doc@vger.kernel.org, Szabolcs Nagy , heiko.carstens@de.ibm.com, cmetcalf@ezchip.com, Yury Norov , "Dr. Philipp Tomsich" , matt.spencer@arm.com, "Joseph S. Myers" , linux-arch@vger.kernel.org, zhouchengming1@huawei.com, sellcey@caviumnetworks.com, Prasun Kapoor , agraf@suse.de, Geert Uytterhoeven , Ding Tianhong , kilobyte@angband.pl, manuel.montezelo@gmail.com, arnd@arndb.de, Andrew Pinski , linyongting@huawei.com, klimov.linux@gmail.com, broonie@kernel.org, linux-arm-kernel@lists.infradead.org, GNU C Library , Nathan_Lynch@mentor.com, linux-kernel@vger.kernel.org, hanjun.guo@linaro.org, schwidefsky@de.ibm.com, David Miller , christoph.muellner@theobroma-systems.com Subject: Re: ILP32 for ARM64 - testing with lmbench Message-ID: <20161205141312.GC14429@e104818-lin.cambridge.arm.com> References: <1477081997-4770-1-git-send-email-ynorov@caviumnetworks.com> <20161028124659.GA24131@yury-N73SV> <266952F2-53F5-4D5E-83F0-6C8203092F67@linaro.org> <120041af-f4e9-5b6f-36dc-7d3535a1f01c@huawei.com> <0adfca97-1624-8eac-8149-da447525ad65@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0adfca97-1624-8eac-8149-da447525ad65@huawei.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 05, 2016 at 06:16:09PM +0800, Zhangjian (Bamvor) wrote: > Do you have suggestion of next move of upstreaming ILP32? I mentioned the steps a few time before. I'm pasting them again here: 1. Complete the review of the Linux patches and ABI (no merge yet) 2. Review the corresponding glibc patches (no merge yet) 3. Ask (Linaro, Cavium) for toolchain + filesystem (pre-built and more than just busybox) to be able to reproduce the testing in ARM 4. More testing (LTP, trinity, performance regressions etc.) 5. Move the ILP32 PCS out of beta (based on the results from 4) 6. Check the market again to see if anyone still needs ILP32 7. Based on 6, decide whether to merge the kernel and glibc patches What's not explicitly mentioned in step 4 is glibc testing. Point 5 is ARM's responsibility (toolchain folk). > There are already the test results of lmbench and specint. Do you they > are ok or need more data to prove no regression? I would need to reproduce the tests myself, see step 3. > I have also noticed that there are ILP32 failures in glibc testsuite. > Is it the only blocker for merge ILP32(in technology part)? It's probably not the only blocker but I have to review the kernel patches again to make sure. I'd also like to see whether the libc-alpha community is ok with the glibc counterpart (but don't merge the patches until the ABI is agreed on both sides). On performance, I want to make sure there are no regressions on AArch32/compat and AArch64/LP64. -- Catalin From mboxrd@z Thu Jan 1 00:00:00 1970 From: Catalin Marinas Subject: Re: ILP32 for ARM64 - testing with lmbench Date: Mon, 5 Dec 2016 14:13:12 +0000 Message-ID: <20161205141312.GC14429@e104818-lin.cambridge.arm.com> References: <1477081997-4770-1-git-send-email-ynorov@caviumnetworks.com> <20161028124659.GA24131@yury-N73SV> <266952F2-53F5-4D5E-83F0-6C8203092F67@linaro.org> <120041af-f4e9-5b6f-36dc-7d3535a1f01c@huawei.com> <0adfca97-1624-8eac-8149-da447525ad65@huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <0adfca97-1624-8eac-8149-da447525ad65@huawei.com> Sender: linux-doc-owner@vger.kernel.org To: "Zhangjian (Bamvor)" Cc: Maxim Kuvyrkov , linux-doc@vger.kernel.org, Szabolcs Nagy , heiko.carstens@de.ibm.com, cmetcalf@ezchip.com, Yury Norov , "Dr. Philipp Tomsich" , matt.spencer@arm.com, "Joseph S. Myers" , linux-arch@vger.kernel.org, zhouchengming1@huawei.com, sellcey@caviumnetworks.com, Prasun Kapoor , agraf@suse.de, Geert Uytterhoeven , Ding Tianhong , kilobyte@angband.pl, manuel.montezelo@gmail.com, arnd@arndb.de, Andrew Pinski , linyongting@huawei.com, klimov.linux@gmail.com, broonie@kernel.org, linux-arm-kernel@lists.infradead.org, GNU List-Id: linux-arch.vger.kernel.org On Mon, Dec 05, 2016 at 06:16:09PM +0800, Zhangjian (Bamvor) wrote: > Do you have suggestion of next move of upstreaming ILP32? I mentioned the steps a few time before. I'm pasting them again here: 1. Complete the review of the Linux patches and ABI (no merge yet) 2. Review the corresponding glibc patches (no merge yet) 3. Ask (Linaro, Cavium) for toolchain + filesystem (pre-built and more than just busybox) to be able to reproduce the testing in ARM 4. More testing (LTP, trinity, performance regressions etc.) 5. Move the ILP32 PCS out of beta (based on the results from 4) 6. Check the market again to see if anyone still needs ILP32 7. Based on 6, decide whether to merge the kernel and glibc patches What's not explicitly mentioned in step 4 is glibc testing. Point 5 is ARM's responsibility (toolchain folk). > There are already the test results of lmbench and specint. Do you they > are ok or need more data to prove no regression? I would need to reproduce the tests myself, see step 3. > I have also noticed that there are ILP32 failures in glibc testsuite. > Is it the only blocker for merge ILP32(in technology part)? It's probably not the only blocker but I have to review the kernel patches again to make sure. I'd also like to see whether the libc-alpha community is ok with the glibc counterpart (but don't merge the patches until the ABI is agreed on both sides). On performance, I want to make sure there are no regressions on AArch32/compat and AArch64/LP64. -- Catalin From mboxrd@z Thu Jan 1 00:00:00 1970 From: catalin.marinas@arm.com (Catalin Marinas) Date: Mon, 5 Dec 2016 14:13:12 +0000 Subject: ILP32 for ARM64 - testing with lmbench In-Reply-To: <0adfca97-1624-8eac-8149-da447525ad65@huawei.com> References: <1477081997-4770-1-git-send-email-ynorov@caviumnetworks.com> <20161028124659.GA24131@yury-N73SV> <266952F2-53F5-4D5E-83F0-6C8203092F67@linaro.org> <120041af-f4e9-5b6f-36dc-7d3535a1f01c@huawei.com> <0adfca97-1624-8eac-8149-da447525ad65@huawei.com> Message-ID: <20161205141312.GC14429@e104818-lin.cambridge.arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, Dec 05, 2016 at 06:16:09PM +0800, Zhangjian (Bamvor) wrote: > Do you have suggestion of next move of upstreaming ILP32? I mentioned the steps a few time before. I'm pasting them again here: 1. Complete the review of the Linux patches and ABI (no merge yet) 2. Review the corresponding glibc patches (no merge yet) 3. Ask (Linaro, Cavium) for toolchain + filesystem (pre-built and more than just busybox) to be able to reproduce the testing in ARM 4. More testing (LTP, trinity, performance regressions etc.) 5. Move the ILP32 PCS out of beta (based on the results from 4) 6. Check the market again to see if anyone still needs ILP32 7. Based on 6, decide whether to merge the kernel and glibc patches What's not explicitly mentioned in step 4 is glibc testing. Point 5 is ARM's responsibility (toolchain folk). > There are already the test results of lmbench and specint. Do you they > are ok or need more data to prove no regression? I would need to reproduce the tests myself, see step 3. > I have also noticed that there are ILP32 failures in glibc testsuite. > Is it the only blocker for merge ILP32(in technology part)? It's probably not the only blocker but I have to review the kernel patches again to make sure. I'd also like to see whether the libc-alpha community is ok with the glibc counterpart (but don't merge the patches until the ABI is agreed on both sides). On performance, I want to make sure there are no regressions on AArch32/compat and AArch64/LP64. -- Catalin