From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 00/23] ILP32 for ARM64
Date: Mon, 5 Oct 2015 16:58:59 +0100 [thread overview]
Message-ID: <20151005155857.GA5557@MBP.local> (raw)
In-Reply-To: <D23487FC.908DE%pkapoor@caviumnetworks.com>
On Sat, Oct 03, 2015 at 02:18:57AM +0000, Kapoor, Prasun wrote:
> On 10/2/15, 2:37 AM, "Catalin Marinas" <catalin.marinas@arm.com> wrote:
> >So, at the time, following x32 discussions, we thought of using the
> >native ABI as much as possible. However, two important things happened
> >since:
> >
> >1. libc community didn't like breaking the POSIX compliance
> >2. No-one seems desperate for ILP32 on AArch64
> >
> >(1) is a fair point and I would rather be careful as we don't know the
> >extent of the code affected. In the meantime, we've also had ongoing
> >work for addressing the 2038 issue on 32-bit architectures.
> >
> >The second point is equally important. The benchmarks I've seen didn't
> >show a significant improvement and the messages I got on various
> >channels pretty much labeled ILP32 as a transitional stage to full LP64.
> >In this case, we need to balance the benefits of a close to native ABI
> >(future proof, slightly higher performance) vs. the cost of maintaining
> >such ABI in the kernel on the long term, especially if it's not widely
> >used/tested.
>
> For us ILP32 is not about putting this into our product flier at all, it
> is about supporting real applications. We have an existing product line of
> MIPS based SoCs where a large number of N32 (an exact equivalent of ILP32)
> applications are currently in production. Our customers are looking to
> bring those applications (mostly in Networking and Telecom space) over to
> ARMv8.
>
> We think its an extremely risky strategy to say either future processors
> should incur the additional cost (power and complexity) of implementing
> Aarch32 instruction set or have no way of supporting 32 bit applications
> at all.
Well, given that Cavium posted only 3 versions of this series since
September 2013, it doesn't seem critical at all.
> Apart from there being an installed base of 32 bit networking and telecom
> applications, we have also seen non-trivial performance gains with ILP32
> (for example, our SPECINT score goes up by 7% with ILP32 compared to
> LP64).
It would be good to re-run the benchmarks with the latest gcc since
LP64/AArch64 support has evolved in the meantime.
--
Catalin
next prev parent reply other threads:[~2015-10-05 15:58 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-29 22:13 [PATCH v5 00/23] ILP32 for ARM64 Yury Norov
2015-09-29 22:13 ` [PATCH v5 01/23] arm64:ilp32: add documentation on the ILP32 ABI " Yury Norov
2015-09-29 22:13 ` [PATCH v5 02/23] arm64: ensure the kernel is compiled for LP64 Yury Norov
2015-09-29 22:14 ` [PATCH v5 03/23] arm64: rename COMPAT to AARCH32_EL0 in Kconfig Yury Norov
2015-10-06 9:21 ` Andrey Konovalov
2015-09-29 22:14 ` [PATCH v5 04/23] arm64: change some CONFIG_COMPAT over to use CONFIG_AARCH32_EL0 instead Yury Norov
2015-09-30 3:36 ` kbuild test robot
2015-09-30 5:35 ` kbuild test robot
2015-10-06 9:21 ` Andrey Konovalov
2015-09-29 22:14 ` [PATCH v5 05/23] arm64:ilp32: expose 'kernel_long' as 'long long' for ILP32 Yury Norov
2015-09-29 22:14 ` [PATCH v5 06/23] arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64 Yury Norov
2015-09-29 22:14 ` [PATCH v5 07/23] arm64:ilp32: share signal structures between ILP32 and LP64 ABIs Yury Norov
2015-09-29 22:14 ` [PATCH v5 08/23] arm64:ilp32: use 64bit syscall-names for ILP32 when passing 64bit registers Yury Norov
2015-09-29 22:14 ` [PATCH v5 09/23] arm64:ilp32: use non-compat syscall names for ILP32 as for LP64 Yury Norov
2015-09-29 22:14 ` [PATCH v5 10/23] arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat) Yury Norov
2015-09-30 3:48 ` kbuild test robot
2015-10-06 9:21 ` Andrey Konovalov
2015-10-07 16:13 ` Yury Norov
2015-09-29 22:14 ` [PATCH v5 11/23] arm64:ilp32: add is_ilp32_compat_{task, thread} and TIF_32BIT_AARCH64 Yury Norov
2015-09-29 22:14 ` [PATCH v5 12/23] arm64:ilp32: COMPAT_USE_64BIT_TIME is true for ILP32 tasks Yury Norov
2015-09-29 22:14 ` [PATCH v5 13/23] arm64:ilp32: share HWCAP between LP64 and ILP32 Yury Norov
2015-09-29 22:14 ` [PATCH v5 14/23] arm64:ilp32 use the native LP64 'start_thread' for ILP32 threads Yury Norov
2015-09-29 22:14 ` [PATCH v5 15/23] arm64:ilp32: support core dump generation for ILP32 Yury Norov
2015-09-29 22:14 ` [PATCH v5 16/23] arm64: add support for starting ILP32 (ELFCLASS32) binaries Yury Norov
2015-09-29 22:14 ` [PATCH v5 17/23] arm64:ilp32: add vdso-ilp32 and use for signal return Yury Norov
2015-09-30 4:06 ` Nathan Lynch
2015-10-01 19:44 ` Yury Norov
2015-10-01 19:54 ` Dr. Philipp Tomsich
2015-09-29 22:14 ` [PATCH v5 18/23] ptrace: Allow compat to use the native siginfo Yury Norov
2015-09-29 22:14 ` [PATCH v5 19/23] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Yury Norov
2015-09-29 22:14 ` [PATCH v5 20/23] arm64:ilp32: use the native siginfo instead of the compat siginfo Yury Norov
2015-09-29 22:14 ` [PATCH v5 21/23] arm64:ilp32: change COMPAT_ELF_PLATFORM to report a a subplatform for ILP32 Yury Norov
2015-09-29 22:14 ` [PATCH v5 22/23] aarch64: ilp32: msgrcv, msgsnd handlers Yury Norov
2015-09-29 22:14 ` [PATCH v5 23/23] arm64:ilp32: add ARM64_ILP32 to Kconfig Yury Norov
2015-09-30 10:19 ` [PATCH v5 00/23] ILP32 for ARM64 Catalin Marinas
2015-09-30 16:41 ` Mark Brown
2015-10-01 11:19 ` Catalin Marinas
2015-10-01 11:36 ` Mark Brown
2015-10-01 16:42 ` Andrey Konovalov
2015-10-01 19:33 ` Yury Norov
2015-10-01 19:15 ` Yury Norov
2015-10-01 21:28 ` Arnd Bergmann
2015-10-01 21:49 ` Pinski, Andrew
2015-10-02 9:37 ` Catalin Marinas
2015-10-03 2:18 ` Kapoor, Prasun
2015-10-05 15:58 ` Catalin Marinas [this message]
2015-10-05 21:00 ` Pinski, Andrew
2015-10-05 19:10 ` Yury Norov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151005155857.GA5557@MBP.local \
--to=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).