This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 01/23] all: syscall wrappers: add documentation
- From: Arnd Bergmann <arnd at arndb dot de>
- To: David Miller <davem at davemloft dot net>
- Cc: ynorov at caviumnetworks dot com, catalin dot marinas at arm dot com, linux-arm-kernel at lists dot infradead dot org, linux-kernel at vger dot kernel dot org, linux-doc at vger dot kernel dot org, linux-arch at vger dot kernel dot org, linux-s390 at vger dot kernel dot org, libc-alpha at sourceware dot org, schwidefsky at de dot ibm dot com, heiko dot carstens at de dot ibm dot com, pinskia at gmail dot com, broonie at kernel dot org, joseph at codesourcery dot com, christoph dot muellner at theobroma-systems dot com, bamvor dot zhangjian at huawei dot com, szabolcs dot nagy at arm dot com, klimov dot linux at gmail dot com, Nathan_Lynch at mentor dot com, agraf at suse dot de, Prasun dot Kapoor at caviumnetworks dot com, kilobyte at angband dot pl, geert at linux-m68k dot org, philipp dot tomsich at theobroma-systems dot com
- Date: Wed, 25 May 2016 22:47:33 +0200
- Subject: Re: [PATCH 01/23] all: syscall wrappers: add documentation
- Authentication-results: sourceware.org; auth=none
- References: <1464048292-30136-2-git-send-email-ynorov at caviumnetworks dot com> <20160525200327 dot GA22395 at yury-N73SV> <20160525 dot 132145 dot 1271448744307448631 dot davem at davemloft dot net>
On Wednesday, May 25, 2016 1:21:45 PM CEST David Miller wrote:
> From: Yury Norov <ynorov@caviumnetworks.com>
> Date: Wed, 25 May 2016 23:03:27 +0300
>
> > On Wed, May 25, 2016 at 12:30:17PM -0700, David Miller wrote:
> >> From: Yury Norov <ynorov@caviumnetworks.com>
> >> Date: Tue, 24 May 2016 03:04:30 +0300
> >>
> >> > +To clear that top halves, automatic wrappers are introduced. They clear all
> >> > +required registers before passing control to regular syscall handler.
> >>
> >> Why have one of these for every single compat system call, rather than
> >> simply clearing the top half of all of these registers unconditionally
> >> in the 32-bit system call trap before the system call is invoked?
> >>
> >> That's what we do on sparc64.
> >>
> >> And with that, you only need wrappers for the case where there needs
> >> to be proper sign extention of a 32-bit signed argument.
> >
> > It was discussed as one of possible solutions. The downside of it is
> > that we cannot pass 64-bit types (like off_t) in single register.
>
> Wrappers can be added for the cases where you'd like to do that.
If we clear the upper halves on the initial entry, we can't use a wrapper
to restore them, so would have to instead pass them as register
pairs as we do on the other 32-bit architectures.
> > The other downside is that we clear top halves for every single
> > syscall, and it looks excessive. So, from spark64 and s390 approaches
> > we choosed second.
>
> It's like 4 cpu cycles even on crappy sparc64 cpus which only dual
> issue. :)
>
> And that's a pretty low cost for the benefits if you ask me.
To clarify what we are talking about: These syscalls that normally
pass 64-bit arguments as register pairs are intentionally overridden
to make them faster on ilp32 mode compare to other compat modes:
+#define compat_sys_fadvise64_64 sys_fadvise64_64
+#define compat_sys_fallocate sys_fallocate
+#define compat_sys_ftruncate64 sys_ftruncate
+#define compat_sys_lookup_dcookie sys_lookup_dcookie
+#define compat_sys_readahead sys_readahead
+#define compat_sys_sync_file_range sys_sync_file_range
+#define compat_sys_truncate64 sys_truncate
+#define sys_llseek sys_lseek
+static unsigned long compat_sys_pread64(unsigned int fd,
+ compat_uptr_t __user *ubuf, compat_size_t count, off_t offset)
+{
+ return sys_pread64(fd, (char *) ubuf, count, offset);
+}
+
+static unsigned long compat_sys_pwrite64(unsigned int fd,
+ compat_uptr_t __user *ubuf, compat_size_t count, off_t offset)
+{
+ return sys_pwrite64(fd, (char *) ubuf, count, offset);
+}
If we use the normal calling conventions, we could remove these overrides
along with the respective special-case handling in glibc. None of them
look particularly performance-sensitive, but I could be wrong there.
Arnd