Linux-MIPS Archive on lore.kernel.org
 help / color / Atom feed
From: Vincenzo Frascino <vincenzo.frascino@arm.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arch <linux-arch@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-mips@vger.kernel.org,
	"open list:KERNEL SELFTEST FRAMEWORK" 
	<linux-kselftest@vger.kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Russell King <linux@armlinux.org.uk>,
	Ralf Baechle <ralf@linux-mips.org>,
	Paul Burton <paul.burton@mips.com>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Mark Salyzyn <salyzyn@android.com>,
	Peter Collingbourne <pcc@google.com>,
	Shuah Khan <shuah@kernel.org>,
	Dmitry Safonov <0x7f454c46@gmail.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Huw Davies <huw@codeweavers.com>
Subject: Re: [PATCH v6 00/19] Unify vDSOs across more architectures
Date: Wed, 5 Jun 2019 15:32:53 +0100
Message-ID: <ea965b5e-9be8-02e9-5dc0-ebbb330bcc2c@arm.com> (raw)
In-Reply-To: <CAK8P3a3nxd7F5zLyD1SVarKjjKC0qvMEN8wP6R7zHY9HKdoe0w@mail.gmail.com>

On 6/4/19 1:12 PM, Arnd Bergmann wrote:
> On Tue, Jun 4, 2019 at 2:05 PM Vincenzo Frascino
> <vincenzo.frascino@arm.com> wrote:
>> 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:
>>> 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.
> 
> It's clear that the vdso version is much faster, my point was that
> I could not think of any use case that cared about it being fast.
> 

I do not know of any use case that cares, my point was that since we need to
implement it in the generic library for some architectures, for symmetry we can
extend it to all the architectures that support the generic vdso library.

> If there is a good reason for it, I also don't mind adding a
> clock_getres_time64() vdso version everywhere.

Totally agree on this.

> 
>>> 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?
> 
> I actually never understood the point of symbol versioning
> in the vdso. What does that gain us? Note that there are
> no conflicting symbol names between the versions, and
> that nothing enforces the kernel headers to match the
> symbol version used when linking.
>

My understanding, based on [1] and [2] is that the version defines the minimum
kernel version from when a specific symbols is exposed and whenever this symbol
is requested from the vDSO the correct version needs to be specified.
Every "new" library, dealing with an "old" kernel, compliant with the exposed
ABI should implement the vDSO calls in this way and provide a fallback if the
vDSO function is not present (i.e. [3]).

[1] Documentation/ABI/stable/vdso
[2] tools/testing/selftests/vDSO/parse_vdso.c
[3]
https://github.com/lattera/glibc/blob/master/sysdeps/unix/sysv/linux/aarch64/gettimeofday.c


>       Arnd
> 

-- 
Regards,
Vincenzo

  reply index

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-30 14:15 Vincenzo Frascino
2019-05-30 14:15 ` [PATCH v6 01/19] kernel: Standardize vdso_datapage Vincenzo Frascino
2019-05-31  8:16   ` Arnd Bergmann
2019-06-04 12:05     ` Vincenzo Frascino
2019-06-10 17:47       ` Huw Davies
2019-06-10  9:27   ` Huw Davies
2019-06-10 10:17     ` Vincenzo Frascino
2019-06-10 10:31       ` Huw Davies
2019-06-10 11:07         ` Vincenzo Frascino
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-31  8:19   ` Arnd Bergmann
2019-06-04 12:08     ` Vincenzo Frascino
2019-06-10  9:31   ` Huw Davies
2019-06-10 10:18     ` Vincenzo Frascino
2019-05-30 14:15 ` [PATCH v6 03/19] kernel: Unify update_vsyscall implementation Vincenzo Frascino
2019-06-10  9:34   ` Huw Davies
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 ` [PATCH v6 05/19] arm64: Build vDSO with -ffixed-x18 Vincenzo Frascino
2019-05-30 14:15 ` [PATCH v6 06/19] arm64: compat: Add missing syscall numbers Vincenzo Frascino
2019-05-30 14:15 ` [PATCH v6 07/19] arm64: compat: Expose signal related structures 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 ` [PATCH v6 09/19] lib: vdso: Add compat support Vincenzo Frascino
2019-05-30 14:15 ` [PATCH v6 10/19] arm64: compat: Add vDSO Vincenzo Frascino
2019-05-30 14:15 ` [PATCH v6 11/19] arm64: Refactor vDSO code 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 ` [PATCH v6 13/19] arm64: elf: vDSO code page discovery 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 ` [PATCH v6 15/19] arm64: Add vDSO compat support Vincenzo Frascino
2019-06-01  9:38   ` Catalin Marinas
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-31  8:32   ` Arnd Bergmann
2019-05-30 14:15 ` [PATCH v6 17/19] mips: " Vincenzo Frascino
2019-05-31  8:34   ` Arnd Bergmann
2019-06-03 14:54     ` Mark Salyzyn
2019-06-03 17:07       ` Arnd Bergmann
2019-05-30 14:15 ` [PATCH v6 18/19] x86: " Vincenzo Frascino
2019-05-30 15:41   ` Michael Kelley
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-31  8:53   ` Arnd Bergmann
2019-05-31  8:46 ` [PATCH v6 00/19] Unify vDSOs across more architectures Arnd Bergmann
2019-06-04 12:04   ` Vincenzo Frascino
2019-06-04 12:12     ` Arnd Bergmann
2019-06-05 14:32       ` Vincenzo Frascino [this message]
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 publically 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=ea965b5e-9be8-02e9-5dc0-ebbb330bcc2c@arm.com \
    --to=vincenzo.frascino@arm.com \
    --cc=0x7f454c46@gmail.com \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=huw@codeweavers.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=linux@rasmusvillemoes.dk \
    --cc=paul.burton@mips.com \
    --cc=pcc@google.com \
    --cc=ralf@linux-mips.org \
    --cc=salyzyn@android.com \
    --cc=shuah@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=will.deacon@arm.com \
    /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

Linux-MIPS Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-mips/0 linux-mips/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-mips linux-mips/ https://lore.kernel.org/linux-mips \
		linux-mips@vger.kernel.org linux-mips@archiver.kernel.org
	public-inbox-index linux-mips

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-mips


AGPL code for this site: git clone https://public-inbox.org/ public-inbox