From: vincenzo.frascino at arm.com (Vincenzo Frascino) Subject: [PATCH v6 00/19] Unify vDSOs across more architectures Date: Tue, 4 Jun 2019 13:04:58 +0100 [thread overview] Message-ID: <d96667d5-e43b-d33a-fbd0-5acfb4904316@arm.com> (raw) In-Reply-To: <CAK8P3a11DE0sXteZoaP_N=mDhx3tXitGKddn1ogtFqJBYO-SCA@mail.gmail.com> Hi Arnd, thank you for your review. On 31/05/2019 09:46, Arnd Bergmann wrote: > On Thu, May 30, 2019 at 4:15 PM Vincenzo Frascino > <vincenzo.frascino at arm.com> wrote: >> >> vDSO (virtual dynamic shared object) is a mechanism that the Linux >> kernel provides as an alternative to system calls to reduce where >> possible the costs in terms of cycles. >> This is possible because certain syscalls like gettimeofday() do >> not write any data and return one or more values that are stored >> in the kernel, which makes relatively safe calling them directly >> as a library function. > > Hi Vincento, > > I've very happy with how this turned out overall, and as far as I can > tell you have addressed all my previous comments. I had another > look through the series and only noticed a few very minor issues. > Thanks! I agree with what you pointed out in the single patches, I will wait for Thomas to review them as well and then will address all the comments in v7. ... > > One open question I touched in my review is whether we want to > have a vdso version of clock_getres() in all architectures or not. > I'd prefer to leave it out because there is very little advantage to > it over the system call (the results don't change at runtime and > can easily be cached by libc if performance ever matters), and > it takes up a small amount of memory for the implementation. > I thought about it and I ended up with what proposed in this patchset mainly for symmetry across all the architectures since in the end they use the same common code. It seems also that there is some performance impact (i.e.): clock-getres-monotonic: libc(system call): 296 nsec/call clock-getres-monotonic: libc(vdso): 5 nsec/call I agree with you though when you say that caching it in the libc is a possibility to overcome the performance impact. > We shouldn't just need it for consistency because all callers > would require implementing a fallback to the system call > anyway, to deal with old kernels. > A way to address this issue would be to use versioning, which seems supported in the vdso library (i.e. arch/x86/entry/vdso/vdso32/vdso32.lds.S). For example for x86 (vdso32) we would have something like: VERSION { LINUX_5.3 (being optimistic here :) ) { global: __vdso_clock_getres; __vdso_clock_gettime64; }; LINUX_2.6 { global: __vdso_clock_gettime; __vdso_gettimeofday; __vdso_time; }; LINUX_2.5 { global: __kernel_vsyscall; __kernel_sigreturn; __kernel_rt_sigreturn; local: *; }; } What do you think? Would this be a viable solution? > If anyone comes up with a good reason why it should be added > after all, let me know and I'll stop mentioning it. > > Arnd > -- Regards, Vincenzo
WARNING: multiple messages have this Message-ID (diff)
From: vincenzo.frascino@arm.com (Vincenzo Frascino) Subject: [PATCH v6 00/19] Unify vDSOs across more architectures Date: Tue, 4 Jun 2019 13:04:58 +0100 [thread overview] Message-ID: <d96667d5-e43b-d33a-fbd0-5acfb4904316@arm.com> (raw) Message-ID: <20190604120458.B2LmxWGYQD-7LtwB1nH7X9rbXS0SFkNjBbV2Oyo8klI@z> (raw) In-Reply-To: <CAK8P3a11DE0sXteZoaP_N=mDhx3tXitGKddn1ogtFqJBYO-SCA@mail.gmail.com> Hi Arnd, thank you for your review. On 31/05/2019 09:46, Arnd Bergmann wrote: > On Thu, May 30, 2019 at 4:15 PM Vincenzo Frascino > <vincenzo.frascino@arm.com> wrote: >> >> vDSO (virtual dynamic shared object) is a mechanism that the Linux >> kernel provides as an alternative to system calls to reduce where >> possible the costs in terms of cycles. >> This is possible because certain syscalls like gettimeofday() do >> not write any data and return one or more values that are stored >> in the kernel, which makes relatively safe calling them directly >> as a library function. > > Hi Vincento, > > I've very happy with how this turned out overall, and as far as I can > tell you have addressed all my previous comments. I had another > look through the series and only noticed a few very minor issues. > Thanks! I agree with what you pointed out in the single patches, I will wait for Thomas to review them as well and then will address all the comments in v7. ... > > One open question I touched in my review is whether we want to > have a vdso version of clock_getres() in all architectures or not. > I'd prefer to leave it out because there is very little advantage to > it over the system call (the results don't change at runtime and > can easily be cached by libc if performance ever matters), and > it takes up a small amount of memory for the implementation. > I thought about it and I ended up with what proposed in this patchset mainly for symmetry across all the architectures since in the end they use the same common code. It seems also that there is some performance impact (i.e.): clock-getres-monotonic: libc(system call): 296 nsec/call clock-getres-monotonic: libc(vdso): 5 nsec/call I agree with you though when you say that caching it in the libc is a possibility to overcome the performance impact. > We shouldn't just need it for consistency because all callers > would require implementing a fallback to the system call > anyway, to deal with old kernels. > A way to address this issue would be to use versioning, which seems supported in the vdso library (i.e. arch/x86/entry/vdso/vdso32/vdso32.lds.S). For example for x86 (vdso32) we would have something like: VERSION { LINUX_5.3 (being optimistic here :) ) { global: __vdso_clock_getres; __vdso_clock_gettime64; }; LINUX_2.6 { global: __vdso_clock_gettime; __vdso_gettimeofday; __vdso_time; }; LINUX_2.5 { global: __kernel_vsyscall; __kernel_sigreturn; __kernel_rt_sigreturn; local: *; }; } What do you think? Would this be a viable solution? > If anyone comes up with a good reason why it should be added > after all, let me know and I'll stop mentioning it. > > Arnd > -- Regards, Vincenzo
next prev parent reply other threads:[~2019-06-04 12:04 UTC|newest] Thread overview: 126+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-30 14:15 [PATCH v6 00/19] Unify vDSOs across more architectures vincenzo.frascino 2019-05-30 14:15 ` Vincenzo Frascino 2019-05-30 14:15 ` [PATCH v6 01/19] kernel: Standardize vdso_datapage vincenzo.frascino 2019-05-30 14:15 ` Vincenzo Frascino 2019-05-31 8:16 ` arnd 2019-05-31 8:16 ` Arnd Bergmann 2019-06-04 12:05 ` vincenzo.frascino 2019-06-04 12:05 ` Vincenzo Frascino 2019-06-10 17:47 ` huw 2019-06-10 17:47 ` Huw Davies 2019-06-10 17:47 ` Huw Davies 2019-06-10 9:27 ` huw 2019-06-10 9:27 ` Huw Davies 2019-06-10 9:27 ` Huw Davies 2019-06-10 10:17 ` vincenzo.frascino 2019-06-10 10:17 ` Vincenzo Frascino 2019-06-10 10:17 ` Vincenzo Frascino 2019-06-10 10:31 ` huw 2019-06-10 10:31 ` Huw Davies 2019-06-10 10:31 ` Huw Davies 2019-06-10 11:07 ` vincenzo.frascino 2019-06-10 11:07 ` Vincenzo Frascino 2019-06-10 11:07 ` Vincenzo Frascino 2019-06-10 11:37 ` huw 2019-06-10 11:37 ` Huw Davies 2019-06-10 11:37 ` Huw Davies 2019-05-30 14:15 ` [PATCH v6 02/19] kernel: Define gettimeofday vdso common code vincenzo.frascino 2019-05-30 14:15 ` Vincenzo Frascino 2019-05-31 8:19 ` arnd 2019-05-31 8:19 ` Arnd Bergmann 2019-06-04 12:08 ` vincenzo.frascino 2019-06-04 12:08 ` Vincenzo Frascino 2019-06-10 9:31 ` huw 2019-06-10 9:31 ` Huw Davies 2019-06-10 9:31 ` Huw Davies 2019-06-10 10:18 ` vincenzo.frascino 2019-06-10 10:18 ` Vincenzo Frascino 2019-06-10 10:18 ` Vincenzo Frascino 2019-05-30 14:15 ` [PATCH v6 03/19] kernel: Unify update_vsyscall implementation vincenzo.frascino 2019-05-30 14:15 ` Vincenzo Frascino 2019-06-10 9:34 ` huw 2019-06-10 9:34 ` Huw Davies 2019-06-10 9:34 ` Huw Davies 2019-06-10 10:19 ` vincenzo.frascino 2019-06-10 10:19 ` Vincenzo Frascino 2019-06-10 10:19 ` Vincenzo Frascino 2019-06-14 11:10 ` Thomas Gleixner 2019-06-14 12:15 ` Vincenzo Frascino 2019-06-14 12:19 ` Thomas Gleixner 2019-06-14 12:25 ` Vincenzo Frascino 2019-06-14 13:07 ` Thomas Gleixner 2019-05-30 14:15 ` [PATCH v6 04/19] arm64: Substitute gettimeofday with C implementation vincenzo.frascino 2019-05-30 14:15 ` Vincenzo Frascino 2019-05-30 14:15 ` [PATCH v6 05/19] arm64: Build vDSO with -ffixed-x18 vincenzo.frascino 2019-05-30 14:15 ` Vincenzo Frascino 2019-05-30 14:15 ` [PATCH v6 06/19] arm64: compat: Add missing syscall numbers vincenzo.frascino 2019-05-30 14:15 ` Vincenzo Frascino 2019-05-30 14:15 ` [PATCH v6 07/19] arm64: compat: Expose signal related structures vincenzo.frascino 2019-05-30 14:15 ` Vincenzo Frascino 2019-05-30 14:15 ` [PATCH v6 08/19] arm64: compat: Generate asm offsets for signals vincenzo.frascino 2019-05-30 14:15 ` Vincenzo Frascino 2019-05-30 14:15 ` [PATCH v6 09/19] lib: vdso: Add compat support vincenzo.frascino 2019-05-30 14:15 ` Vincenzo Frascino 2019-05-30 14:15 ` [PATCH v6 10/19] arm64: compat: Add vDSO vincenzo.frascino 2019-05-30 14:15 ` Vincenzo Frascino 2019-05-30 14:15 ` [PATCH v6 11/19] arm64: Refactor vDSO code vincenzo.frascino 2019-05-30 14:15 ` Vincenzo Frascino 2019-05-30 14:15 ` [PATCH v6 12/19] arm64: compat: vDSO setup for compat layer vincenzo.frascino 2019-05-30 14:15 ` Vincenzo Frascino 2019-05-30 14:15 ` [PATCH v6 13/19] arm64: elf: vDSO code page discovery vincenzo.frascino 2019-05-30 14:15 ` Vincenzo Frascino 2019-05-30 14:15 ` [PATCH v6 14/19] arm64: compat: Get sigreturn trampolines from vDSO vincenzo.frascino 2019-05-30 14:15 ` Vincenzo Frascino 2019-05-30 14:15 ` [PATCH v6 15/19] arm64: Add vDSO compat support vincenzo.frascino 2019-05-30 14:15 ` Vincenzo Frascino 2019-06-01 9:38 ` catalin.marinas 2019-06-01 9:38 ` Catalin Marinas 2019-06-04 12:10 ` vincenzo.frascino 2019-06-04 12:10 ` Vincenzo Frascino 2019-05-30 14:15 ` [PATCH v6 16/19] arm: Add support for generic vDSO vincenzo.frascino 2019-05-30 14:15 ` Vincenzo Frascino 2019-05-31 8:32 ` arnd 2019-05-31 8:32 ` Arnd Bergmann 2019-05-30 14:15 ` [PATCH v6 17/19] mips: " vincenzo.frascino 2019-05-30 14:15 ` Vincenzo Frascino 2019-05-31 8:34 ` arnd 2019-05-31 8:34 ` Arnd Bergmann 2019-06-03 14:54 ` salyzyn 2019-06-03 14:54 ` Mark Salyzyn 2019-06-03 17:07 ` arnd 2019-06-03 17:07 ` Arnd Bergmann 2019-05-30 14:15 ` [PATCH v6 18/19] x86: " vincenzo.frascino 2019-05-30 14:15 ` Vincenzo Frascino 2019-05-30 15:41 ` mikelley 2019-05-30 15:41 ` Michael Kelley 2019-06-04 12:13 ` vincenzo.frascino 2019-06-04 12:13 ` Vincenzo Frascino 2019-06-14 11:15 ` Thomas Gleixner 2019-06-14 21:17 ` Sasha Levin 2019-06-22 14:46 ` Thomas Gleixner 2019-06-23 19:09 ` Sasha Levin 2019-06-23 21:58 ` Stephen Rothwell 2019-06-24 0:24 ` Sasha Levin 2019-06-24 1:20 ` Stephen Rothwell 2019-06-23 22:12 ` Thomas Gleixner 2019-06-24 0:04 ` Michael Kelley 2019-06-24 0:25 ` Thomas Gleixner 2019-06-28 18:40 ` Michael Kelley 2019-05-30 14:15 ` [PATCH v6 19/19] kselftest: Extend vDSO selftest vincenzo.frascino 2019-05-30 14:15 ` Vincenzo Frascino 2019-05-31 8:53 ` arnd 2019-05-31 8:53 ` Arnd Bergmann 2019-05-31 8:46 ` [PATCH v6 00/19] Unify vDSOs across more architectures arnd 2019-05-31 8:46 ` Arnd Bergmann 2019-06-04 12:04 ` vincenzo.frascino [this message] 2019-06-04 12:04 ` Vincenzo Frascino 2019-06-04 12:12 ` arnd 2019-06-04 12:12 ` Arnd Bergmann 2019-06-05 14:32 ` vincenzo.frascino 2019-06-05 14:32 ` Vincenzo Frascino 2019-06-14 12:16 ` Thomas Gleixner 2019-06-14 12:19 ` Vincenzo Frascino 2019-06-20 6:17 ` Shijith Thotton 2019-06-20 8:55 ` Vincenzo Frascino 2019-06-20 16:27 ` Andre Przywara 2019-06-21 9:11 ` Vincenzo Frascino
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=d96667d5-e43b-d33a-fbd0-5acfb4904316@arm.com \ --to=linux-kselftest@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 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).