From: "Dr. Philipp Tomsich" <philipp.tomsich@theobroma-systems.com> To: Arnd Bergmann <arnd@arndb.de> Cc: linux-arm-kernel <linux-arm-kernel@lists.infradead.org>, linux-kernel@vger.kernel.org, Andreas Kraschitzer <andreas.kraschitzer@theobroma-systems.com>, Benedikt Huber <benedikt.huber@theobroma-systems.com>, Catalin Marinas <catalin.marinas@arm.com>, Andrew Pinski <apinski@cavium.com>, Kumar Sankaran <ksankaran@apm.com>, Christoph Muellner <christoph.muellner@theobroma-systems.com> Subject: Re: [PATCH v4 00/24] ILP32 for ARM64 Date: Tue, 14 Apr 2015 00:58:59 +0200 [thread overview] Message-ID: <332955D5-3122-437B-93A1-E1973BE09FCA@theobroma-systems.com> (raw) In-Reply-To: <2507322.zX46IY7aRK@wuerfel> Arnd, > 1. Adding a whole new ABI to the kernel is adding a long-term maintenance > burden, and we don't want to do that just because someone thinks it's a cute > hack or because it might add a few percent in performance of some low-level > benchmark. Please describe in the cover-letter for the patch series > specifically what applications you have in mind that would be using this, and > what the expected timeframe is before users could move to 64-bit user space. There’s a couple of drivers behind getting ILP32 merged on ARM64: (a) There’s plenty of applications (i.e. having a large code-base, but not requiring a 64bit address space) that can’t readily be migrated to LP64 (typically networking or data-storage applications) because they were written assuming an ILP32 data model. Many of these applications will never become suitable for a LP64 data model and will remain locked into ILP32 operating environments. (b) A number of SPEC2006 components (i.e. not low-level benchmarks, but test cases that have been derived from large application use cases) benefit from having a denser data-representation—this includes the mcf, xalancbmk, astar and ometpp. This not an observation specific to ARM64 and can be observed on other architectures as well (e.g. [1] contains data for POWER from 2010). (c) Using AArch32 (assuming that any given ARMv8 processor supports it), is not a real alternative, as 64bit arithmetic is not supported on AArch32 and the AArch32 register set is significantly smaller. Our experience shows that the benefit of having 64bit registers, of a larger register file and of using 64bit arithmetic makes ILP32 a worthwhile improvement over AArch32. In summary, we believe that the need for ILP32 will never disappear on ARM64. In fact, I rather expect the AArch32 compatibility to eventually disapper from further processor designs… which will turn ILP32 into the only option for legacy software. > 2. The ABI follows what x86 has their "x32" ABI. This never saw a lot of > adoption and in retrospect the decision to have separate system calls seems > to not have helped them. My feeling now is that if we add support for the > ARM64 ILP32 ELF ABI, we should better stick to the existing system call ABI > as close as possible and reuse the existing system call table. I realize > that this is a bit controversial, but please let's talk about this now. I see benefits and drawback to merging the system tables. Our philosophy is already somewhat different from x32 and from the original patch-series, as you can see from the changes dealing with stack_t in the ‘sys_rt_sigreturn' and ‘setup_rt_frame’ functions. While these could have been duplicated and specialized for each ABI (as on x32), the attempt was made to keep these changes localized. However, this approach can not always work: if you consider cases like ‘sys_msgsnd’ and ‘compat_sys_msgsnd’, there’s little to no benefit in having just a ‘aarch64_sys_msgsnd’, which then calls either the LP64 or the compat version of the underlying system call. Having a second system call table helps to reduce the overheads in this case and keeps things readable. This comes down to the fact, that a few calls will always be different due to historical baggage in data structures shared between userspace and kernel: 'struct msgbuf’ immediatly comes to mind. I would liken the situation with ARM64 more of MIPS64 with its 64bit ABI and its n32 ABI than to x32… but even there it’s two separate system call tables (although sequentially concatenated). In other words: I fail to see the benefit from keeping the existing table. I you elaborate on how such a solution should look, I might be better able to follow. > The most important aspect here I think is time_t, and while it means starting > out with a system call ABI that is not ready for y2038, at the same time the > purpose of ILP32 support is to support legacy source code that is not 64-bit > safe now, and using 32-bit time_t will make that easier in a lot of ways. > Note that I am also leading the effort to make 32-bit Linux ready for using > 64-bit time_t on all architectures, so ARM64 ILP32 will be fixed as well, it > just won't be any better or worse than the others. The decision to use the 64bit time_t actually came out of Andrew’s earliest patch-set from late 2013… we based the kernel-side of ILP32 on that one, while we focussed on getting all the other components into a working shape. Breaking the C specification (by redefining time_t) always remained a controversial issue on our end, as we knew that the day of switching back to a 32-bit time_t would eventually have to come. Cheers, Phil. [1] https://gcc.gnu.org/wiki/summit2010?action=AttachFile&do=get&target=meissner2.pdf
WARNING: multiple messages have this Message-ID (diff)
From: philipp.tomsich@theobroma-systems.com (Dr. Philipp Tomsich) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v4 00/24] ILP32 for ARM64 Date: Tue, 14 Apr 2015 00:58:59 +0200 [thread overview] Message-ID: <332955D5-3122-437B-93A1-E1973BE09FCA@theobroma-systems.com> (raw) In-Reply-To: <2507322.zX46IY7aRK@wuerfel> Arnd, > 1. Adding a whole new ABI to the kernel is adding a long-term maintenance > burden, and we don't want to do that just because someone thinks it's a cute > hack or because it might add a few percent in performance of some low-level > benchmark. Please describe in the cover-letter for the patch series > specifically what applications you have in mind that would be using this, and > what the expected timeframe is before users could move to 64-bit user space. There?s a couple of drivers behind getting ILP32 merged on ARM64: (a) There?s plenty of applications (i.e. having a large code-base, but not requiring a 64bit address space) that can?t readily be migrated to LP64 (typically networking or data-storage applications) because they were written assuming an ILP32 data model. Many of these applications will never become suitable for a LP64 data model and will remain locked into ILP32 operating environments. (b) A number of SPEC2006 components (i.e. not low-level benchmarks, but test cases that have been derived from large application use cases) benefit from having a denser data-representation?this includes the mcf, xalancbmk, astar and ometpp. This not an observation specific to ARM64 and can be observed on other architectures as well (e.g. [1] contains data for POWER from 2010). (c) Using AArch32 (assuming that any given ARMv8 processor supports it), is not a real alternative, as 64bit arithmetic is not supported on AArch32 and the AArch32 register set is significantly smaller. Our experience shows that the benefit of having 64bit registers, of a larger register file and of using 64bit arithmetic makes ILP32 a worthwhile improvement over AArch32. In summary, we believe that the need for ILP32 will never disappear on ARM64. In fact, I rather expect the AArch32 compatibility to eventually disapper from further processor designs? which will turn ILP32 into the only option for legacy software. > 2. The ABI follows what x86 has their "x32" ABI. This never saw a lot of > adoption and in retrospect the decision to have separate system calls seems > to not have helped them. My feeling now is that if we add support for the > ARM64 ILP32 ELF ABI, we should better stick to the existing system call ABI > as close as possible and reuse the existing system call table. I realize > that this is a bit controversial, but please let's talk about this now. I see benefits and drawback to merging the system tables. Our philosophy is already somewhat different from x32 and from the original patch-series, as you can see from the changes dealing with stack_t in the ?sys_rt_sigreturn' and ?setup_rt_frame? functions. While these could have been duplicated and specialized for each ABI (as on x32), the attempt was made to keep these changes localized. However, this approach can not always work: if you consider cases like ?sys_msgsnd? and ?compat_sys_msgsnd?, there?s little to no benefit in having just a ?aarch64_sys_msgsnd?, which then calls either the LP64 or the compat version of the underlying system call. Having a second system call table helps to reduce the overheads in this case and keeps things readable. This comes down to the fact, that a few calls will always be different due to historical baggage in data structures shared between userspace and kernel: 'struct msgbuf? immediatly comes to mind. I would liken the situation with ARM64 more of MIPS64 with its 64bit ABI and its n32 ABI than to x32? but even there it?s two separate system call tables (although sequentially concatenated). In other words: I fail to see the benefit from keeping the existing table. I you elaborate on how such a solution should look, I might be better able to follow. > The most important aspect here I think is time_t, and while it means starting > out with a system call ABI that is not ready for y2038, at the same time the > purpose of ILP32 support is to support legacy source code that is not 64-bit > safe now, and using 32-bit time_t will make that easier in a lot of ways. > Note that I am also leading the effort to make 32-bit Linux ready for using > 64-bit time_t on all architectures, so ARM64 ILP32 will be fixed as well, it > just won't be any better or worse than the others. The decision to use the 64bit time_t actually came out of Andrew?s earliest patch-set from late 2013? we based the kernel-side of ILP32 on that one, while we focussed on getting all the other components into a working shape. Breaking the C specification (by redefining time_t) always remained a controversial issue on our end, as we knew that the day of switching back to a 32-bit time_t would eventually have to come. Cheers, Phil. [1] https://gcc.gnu.org/wiki/summit2010?action=AttachFile&do=get&target=meissner2.pdf
next prev parent reply other threads:[~2015-04-13 22:59 UTC|newest] Thread overview: 155+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-04-13 19:44 [PATCH v4 00/24] ILP32 for ARM64 Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 01/24] arm64:ilp32: add documentation on the ILP32 ABI " Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 02/24] arm64: ensure the kernel is compiled for LP64 Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 03/24] arm64: rename COMPAT to AARCH32_EL0 in Kconfig Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 04/24] arm64: change some CONFIG_COMPAT over to use CONFIG_AARCH32_EL0 instead Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 05/24] arm64:ilp32: expose 'kernel_long' as 'long long' for ILP32 Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 06/24] arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64 Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 07/24] arm64:ilp32: share signal structures between ILP32 and LP64 ABIs Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 08/24] arm64:ilp32: use 64bit syscall-names for ILP32 when passing 64bit registers Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 09/24] arm64:ilp32: use non-compat syscall names for ILP32 as for LP64 Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 10/24] arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat) Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 11/24] arm64:ilp32: add is_ilp32_compat_{task,thread} and TIF_32BIT_AARCH64 Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 11/24] arm64:ilp32: add is_ilp32_compat_{task, thread} " Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 12/24] arm64:ilp32: COMPAT_USE_64BIT_TIME is true for ILP32 tasks Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 13/24] arm64:ilp32: share HWCAP between LP64 and ILP32 Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 14/24] arm64:ilp32 use the native LP64 'start_thread' for ILP32 threads Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 15/24] arm64:ilp32: support core dump generation for ILP32 Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 16/24] arm64: add support for starting ILP32 (ELFCLASS32) binaries Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 17/24] arm64:ilp32: add vdso-ilp32 and use for signal return Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 18/24] ptrace: Allow compat to use the native siginfo Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 19/24] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 20/24] arm64:ilp32: use compat-syscalls for msgsnd and msgrcv for ILP32 Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 21/24] arm64:ilp32: use the native siginfo instead of the compat siginfo Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 22/24] arm64:ilp32: use compat for stack_t Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-05-05 0:03 ` Pinski, Andrew 2015-05-05 0:03 ` Pinski, Andrew 2015-04-13 19:44 ` [PATCH v4 23/24] arm64:ilp32: change COMPAT_ELF_PLATFORM to report a a subplatform for ILP32 Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 24/24] arm64:ilp32: add ARM64_ILP32 to Kconfig Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 21:01 ` [PATCH v4 00/24] ILP32 for ARM64 Arnd Bergmann 2015-04-13 21:01 ` Arnd Bergmann 2015-04-13 22:58 ` Dr. Philipp Tomsich [this message] 2015-04-13 22:58 ` Dr. Philipp Tomsich 2015-04-14 9:33 ` Dr. Philipp Tomsich 2015-04-14 10:08 ` Arnd Bergmann 2015-04-14 10:08 ` Arnd Bergmann 2015-04-14 10:45 ` Pinski, Andrew 2015-04-14 10:45 ` Pinski, Andrew 2015-04-14 11:14 ` Arnd Bergmann 2015-04-14 11:14 ` Arnd Bergmann 2015-04-14 11:50 ` Dr. Philipp Tomsich 2015-04-14 11:50 ` Dr. Philipp Tomsich 2015-04-14 14:07 ` Arnd Bergmann 2015-04-14 14:07 ` Arnd Bergmann 2015-04-14 14:54 ` Dr. Philipp Tomsich 2015-04-15 12:25 ` Arnd Bergmann 2015-04-15 12:25 ` Arnd Bergmann 2015-04-14 15:00 ` Catalin Marinas 2015-04-14 15:00 ` Catalin Marinas 2015-04-14 22:28 ` Arnd Bergmann 2015-04-14 22:28 ` Arnd Bergmann 2015-04-15 9:18 ` Dr. Philipp Tomsich 2015-04-15 9:18 ` Dr. Philipp Tomsich 2015-04-15 10:01 ` Catalin Marinas 2015-04-15 10:01 ` Catalin Marinas 2015-04-15 15:15 ` Arnd Bergmann 2015-04-15 15:15 ` Arnd Bergmann 2015-04-15 15:38 ` Catalin Marinas 2015-04-15 15:38 ` Catalin Marinas 2015-04-15 17:01 ` Dr. Philipp Tomsich 2015-04-15 17:01 ` Dr. Philipp Tomsich 2015-04-15 17:22 ` Catalin Marinas 2015-04-15 17:22 ` Catalin Marinas 2015-04-15 22:25 ` Alexander Graf 2015-04-15 22:25 ` Alexander Graf 2015-04-16 11:03 ` Catalin Marinas 2015-04-16 11:03 ` Catalin Marinas 2015-04-16 11:19 ` Dr. Philipp Tomsich 2015-04-16 11:19 ` Dr. Philipp Tomsich 2015-04-16 11:33 ` Pinski, Andrew 2015-04-16 11:33 ` Pinski, Andrew 2015-04-16 13:31 ` Catalin Marinas 2015-04-16 13:31 ` Catalin Marinas 2015-04-16 15:21 ` Arnd Bergmann 2015-04-16 15:21 ` Arnd Bergmann 2015-04-17 9:01 ` Catalin Marinas 2015-04-17 9:01 ` Catalin Marinas 2015-04-17 13:17 ` Arnd Bergmann 2015-04-17 13:17 ` Arnd Bergmann 2015-04-17 14:06 ` Alexander Graf 2015-04-17 14:06 ` Alexander Graf 2015-04-17 14:46 ` Catalin Marinas 2015-04-17 14:46 ` Catalin Marinas 2015-04-17 15:15 ` Dr. Philipp Tomsich 2015-04-17 15:15 ` Dr. Philipp Tomsich 2015-04-18 19:24 ` Arnd Bergmann 2015-04-18 19:24 ` Arnd Bergmann 2015-05-04 10:29 ` Arnd Bergmann 2015-05-04 10:29 ` Arnd Bergmann 2015-05-04 10:32 ` Dr. Philipp Tomsich 2015-05-04 10:32 ` Dr. Philipp Tomsich 2015-05-04 14:43 ` Arnd Bergmann 2015-05-04 14:43 ` Arnd Bergmann 2015-05-05 13:11 ` Arnd Bergmann 2015-05-05 13:11 ` Arnd Bergmann 2015-04-17 15:49 ` Arnd Bergmann 2015-04-17 15:49 ` Arnd Bergmann 2015-04-20 15:56 ` Catalin Marinas 2015-04-20 15:56 ` Catalin Marinas 2015-04-20 17:40 ` Arnd Bergmann 2015-04-20 17:40 ` Arnd Bergmann 2015-04-20 14:37 ` Zhangjian (Bamvor) 2015-04-20 14:37 ` Zhangjian (Bamvor) 2015-04-16 14:27 ` Catalin Marinas 2015-04-16 14:27 ` Catalin Marinas 2015-04-14 11:51 ` Pinski, Andrew 2015-04-14 11:51 ` Pinski, Andrew 2015-04-14 14:56 ` Catalin Marinas 2015-04-14 14:56 ` Catalin Marinas 2015-04-14 13:38 ` Catalin Marinas 2015-04-14 13:38 ` Catalin Marinas 2015-04-14 14:47 ` Catalin Marinas 2015-04-14 14:47 ` Catalin Marinas 2015-04-14 15:29 ` Dr. Philipp Tomsich 2015-04-14 15:29 ` Dr. Philipp Tomsich 2015-04-14 16:55 ` Catalin Marinas 2015-04-14 16:55 ` Catalin Marinas 2015-04-15 10:31 ` Dr. Philipp Tomsich 2015-04-15 10:31 ` Dr. Philipp Tomsich 2015-04-15 12:47 ` Arnd Bergmann 2015-04-15 12:47 ` Arnd Bergmann 2015-04-15 12:42 ` Arnd Bergmann 2015-04-15 12:42 ` Arnd Bergmann 2015-04-14 15:44 ` Arnd Bergmann 2015-04-14 15:44 ` Arnd Bergmann 2015-04-15 11:22 ` Catalin Marinas 2015-04-15 11:22 ` Catalin Marinas 2015-04-15 11:50 ` Dr. Philipp Tomsich 2015-04-15 15:49 ` Catalin Marinas 2015-04-15 15:49 ` Catalin Marinas 2015-04-14 9:40 ` Arnd Bergmann 2015-04-14 9:40 ` Arnd Bergmann
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=332955D5-3122-437B-93A1-E1973BE09FCA@theobroma-systems.com \ --to=philipp.tomsich@theobroma-systems.com \ --cc=andreas.kraschitzer@theobroma-systems.com \ --cc=apinski@cavium.com \ --cc=arnd@arndb.de \ --cc=benedikt.huber@theobroma-systems.com \ --cc=catalin.marinas@arm.com \ --cc=christoph.muellner@theobroma-systems.com \ --cc=ksankaran@apm.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.