Re: [PATCH v7 00/25] Unify vDSOs across more architectures
Hi Paul, On 25/06/2019 18:11, Paul Burton wrote: > Hi Vincenzo, > > On Tue, Jun 25, 2019 at 12:16:55AM +0100, Vincenzo Frascino wrote: >> In the end I concluded that all the errors seen here depend on the fact that >> I >> tested my vdso implementation on MIPS32el only (as stated in the cover >> letter) >> and that when I tried to compile a 32BIT binary on a 64BIT configuration I >> did >> it wrongly for two reasons, for N32 and O32 binaries: >> - we need to undefine CONFIG_64BIT and define CONFIG_32BIT >> - we need to define CONFIG_GENERIC_ATOMIC64 >> >> I have a fix for this (patch in attachment), but I do not have the hardware >> to >> test it. If you could provide some feedback would be appreciated (really >> want to >> see MIPS merged with the other archs in 5.3 :) ). > > Thanks for the quick turnaround on your patch! > > I'm certainly willing to test it, but in a few hours I'll be spending > the bulk of a day on airplanes[1] so it might take a few days until I > get to it. > Sounds like a plan. Let us know when you have an update. > Thanks, > Paul > > [1] ...and travel isn't the hackathon it used to be with my 9 month old > son around :) > -- Regards, Vincenzo
Re: [PATCH v7 00/25] Unify vDSOs across more architectures
Hi Vincenzo, On Tue, Jun 25, 2019 at 12:16:55AM +0100, Vincenzo Frascino wrote: > In the end I concluded that all the errors seen here depend on the fact that I > tested my vdso implementation on MIPS32el only (as stated in the cover letter) > and that when I tried to compile a 32BIT binary on a 64BIT configuration I did > it wrongly for two reasons, for N32 and O32 binaries: > - we need to undefine CONFIG_64BIT and define CONFIG_32BIT > - we need to define CONFIG_GENERIC_ATOMIC64 > > I have a fix for this (patch in attachment), but I do not have the hardware to > test it. If you could provide some feedback would be appreciated (really want > to > see MIPS merged with the other archs in 5.3 :) ). Thanks for the quick turnaround on your patch! I'm certainly willing to test it, but in a few hours I'll be spending the bulk of a day on airplanes[1] so it might take a few days until I get to it. Thanks, Paul [1] ...and travel isn't the hackathon it used to be with my 9 month old son around :)
Re: [PATCH v7 00/25] Unify vDSOs across more architectures
Hi Paul,
thank you for your review.
On 6/24/19 7:41 PM, Paul Burton wrote:
> Hello,
>
> On Mon, Jun 24, 2019 at 02:34:24AM +0200, Thomas Gleixner wrote:
>> I did not merge the ARM and MIPS parts as they lack any form of
>> acknowlegment from their maintainers. Please talk to those folks. If they
>> ack/review the changes then I can pick them up and they go into 5.3 or they
>> have to go in a later cycle. Nevertheless it was well worth the trouble to
>> have those conversions done to confirm that the new common library fits a
>> bunch of different architectures.
>
> Apologies for not being more proactive on the MIPS front here; life &
> work are extra busy at the moment... But thanks Vincenzo for including
> MIPS in the work here.
>
No problem.
> Unfortunately after applying the 3 MIPS patches (19-21) atop the current
> tip.git timers/vdso branch at ecf9db3d1f1a ("x86/vdso: Give the
> [ph]vclock_page declarations real types") I see build failures for the
> o32 compat VDSO, shown below. This is using the gcc 8.1.0 mips-linux
> toolchain from here:
>
>
> https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/x86_64-gcc-8.1.0-nolibc-mips-linux.tar.xz
>
> Configuration is 64r6el_defconfig. The following helps remove the
> implicit declaration warnings (and eww to including C files via CFLAGS),
> but it still doesn't build:
>
> diff --git a/arch/mips/vdso/Makefile b/arch/mips/vdso/Makefile
> index 95df49402a53..aa38049bdb24 100644
> --- a/arch/mips/vdso/Makefile
> +++ b/arch/mips/vdso/Makefile
> @@ -36,6 +36,8 @@ aflags-vdso := $(ccflags-vdso) \
>
>ifneq ($(c-gettimeofday-y),)
>CFLAGS_vgettimeofday.o = -include $(c-gettimeofday-y)
> +CFLAGS_vgettimeofday-o32.o = -include $(c-gettimeofday-y)
> +CFLAGS_vgettimeofday-n32.o = -include $(c-gettimeofday-y)
>endif
>
> CFLAGS_REMOVE_vgettimeofday.o = -pg
>
> So the MIPS bits here need more work.
>
I admit, the one proposed was a nice challenge and it took me a while to
understand the differences in between the O32, N32 and N64 binaries and what was
causing the reported issue.
In the end I concluded that all the errors seen here depend on the fact that I
tested my vdso implementation on MIPS32el only (as stated in the cover letter)
and that when I tried to compile a 32BIT binary on a 64BIT configuration I did
it wrongly for two reasons, for N32 and O32 binaries:
- we need to undefine CONFIG_64BIT and define CONFIG_32BIT
- we need to define CONFIG_GENERIC_ATOMIC64
I have a fix for this (patch in attachment), but I do not have the hardware to
test it. If you could provide some feedback would be appreciated (really want to
see MIPS merged with the other archs in 5.3 :) ).
> Thanks,
> Paul
>
> CC arch/mips/vdso/vgettimeofday-o32.o
> In file included from ./include/linux/bitops.h:19,
> from ./include/linux/kernel.h:12,
> from ./include/linux/list.h:9,
> from ./include/linux/preempt.h:11,
> from ./include/linux/spinlock.h:51,
> from ./include/linux/seqlock.h:36,
> from ./include/linux/time.h:6,
> from arch/mips/vdso/vgettimeofday.c:10:
> ./arch/mips/include/asm/bitops.h: In function '__fls':
> ./arch/mips/include/asm/bitops.h:518:21: warning: left shift count >= width
> of type [-Wshift-count-overflow]
> if (!(word & (~0ul << 32))) {
> ^~
> ./arch/mips/include/asm/bitops.h:520:8: warning: left shift count >= width of
> type [-Wshift-count-overflow]
>word <<= 32;
> ^~~
> ./arch/mips/include/asm/bitops.h:523:21: warning: left shift count >= width
> of type [-Wshift-count-overflow]
> if (!(word & (~0ul << (BITS_PER_LONG-16 {
> ^~
> ./arch/mips/include/asm/bitops.h:527:21: warning: left shift count >= width
> of type [-Wshift-count-overflow]
> if (!(word & (~0ul << (BITS_PER_LONG-8 {
> ^~
> ./arch/mips/include/asm/bitops.h:531:21: warning: left shift count >= width
> of type [-Wshift-count-overflow]
> if (!(word & (~0ul << (BITS_PER_LONG-4 {
> ^~
> ./arch/mips/include/asm/bitops.h:535:21: warning: left shift count >= width
> of type [-Wshift-count-overflow]
> if (!(word & (~0ul << (BITS_PER_LONG-2 {
> ^~
> ./arch/mips/include/asm/bitops.h:539:21: warning: left shift count >= width
> of type [-Wshift-count-overflow]
> if (!(word & (~0ul << (BITS_PER_LONG-1
> ^~
> In file included from ./arch/mips/include/asm/mmiowb.h:5,
> from ./include/linux/spinlock.h:60,
> from ./include/linux/seqlock.h:36,
> from ./include/linux/time.h:6,
> from arch/mips/vdso/vgettimeofday.c:10:
> ./arch/mips/include/asm/io.h: In function 'phys_to_virt':
> ./arch/mips/include/asm/io.h:136:9: warning: cast to pointer from integer of
> different size [-Wint-to-pointer-ca
Re: [PATCH v7 00/25] Unify vDSOs across more architectures
Hello,
On Mon, Jun 24, 2019 at 02:34:24AM +0200, Thomas Gleixner wrote:
> I did not merge the ARM and MIPS parts as they lack any form of
> acknowlegment from their maintainers. Please talk to those folks. If they
> ack/review the changes then I can pick them up and they go into 5.3 or they
> have to go in a later cycle. Nevertheless it was well worth the trouble to
> have those conversions done to confirm that the new common library fits a
> bunch of different architectures.
Apologies for not being more proactive on the MIPS front here; life &
work are extra busy at the moment... But thanks Vincenzo for including
MIPS in the work here.
Unfortunately after applying the 3 MIPS patches (19-21) atop the current
tip.git timers/vdso branch at ecf9db3d1f1a ("x86/vdso: Give the
[ph]vclock_page declarations real types") I see build failures for the
o32 compat VDSO, shown below. This is using the gcc 8.1.0 mips-linux
toolchain from here:
https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/x86_64-gcc-8.1.0-nolibc-mips-linux.tar.xz
Configuration is 64r6el_defconfig. The following helps remove the
implicit declaration warnings (and eww to including C files via CFLAGS),
but it still doesn't build:
diff --git a/arch/mips/vdso/Makefile b/arch/mips/vdso/Makefile
index 95df49402a53..aa38049bdb24 100644
--- a/arch/mips/vdso/Makefile
+++ b/arch/mips/vdso/Makefile
@@ -36,6 +36,8 @@ aflags-vdso := $(ccflags-vdso) \
ifneq ($(c-gettimeofday-y),)
CFLAGS_vgettimeofday.o = -include $(c-gettimeofday-y)
+CFLAGS_vgettimeofday-o32.o = -include $(c-gettimeofday-y)
+CFLAGS_vgettimeofday-n32.o = -include $(c-gettimeofday-y)
endif
CFLAGS_REMOVE_vgettimeofday.o = -pg
So the MIPS bits here need more work.
Thanks,
Paul
CC arch/mips/vdso/vgettimeofday-o32.o
In file included from ./include/linux/bitops.h:19,
from ./include/linux/kernel.h:12,
from ./include/linux/list.h:9,
from ./include/linux/preempt.h:11,
from ./include/linux/spinlock.h:51,
from ./include/linux/seqlock.h:36,
from ./include/linux/time.h:6,
from arch/mips/vdso/vgettimeofday.c:10:
./arch/mips/include/asm/bitops.h: In function '__fls':
./arch/mips/include/asm/bitops.h:518:21: warning: left shift count >= width of
type [-Wshift-count-overflow]
if (!(word & (~0ul << 32))) {
^~
./arch/mips/include/asm/bitops.h:520:8: warning: left shift count >= width of
type [-Wshift-count-overflow]
word <<= 32;
^~~
./arch/mips/include/asm/bitops.h:523:21: warning: left shift count >= width of
type [-Wshift-count-overflow]
if (!(word & (~0ul << (BITS_PER_LONG-16 {
^~
./arch/mips/include/asm/bitops.h:527:21: warning: left shift count >= width of
type [-Wshift-count-overflow]
if (!(word & (~0ul << (BITS_PER_LONG-8 {
^~
./arch/mips/include/asm/bitops.h:531:21: warning: left shift count >= width of
type [-Wshift-count-overflow]
if (!(word & (~0ul << (BITS_PER_LONG-4 {
^~
./arch/mips/include/asm/bitops.h:535:21: warning: left shift count >= width of
type [-Wshift-count-overflow]
if (!(word & (~0ul << (BITS_PER_LONG-2 {
^~
./arch/mips/include/asm/bitops.h:539:21: warning: left shift count >= width of
type [-Wshift-count-overflow]
if (!(word & (~0ul << (BITS_PER_LONG-1
^~
In file included from ./arch/mips/include/asm/mmiowb.h:5,
from ./include/linux/spinlock.h:60,
from ./include/linux/seqlock.h:36,
from ./include/linux/time.h:6,
from arch/mips/vdso/vgettimeofday.c:10:
./arch/mips/include/asm/io.h: In function 'phys_to_virt':
./arch/mips/include/asm/io.h:136:9: warning: cast to pointer from integer of
different size [-Wint-to-pointer-cast]
return (void *)(address + PAGE_OFFSET - PHYS_OFFSET);
^
In file included from ./include/linux/bitops.h:5,
from ./include/linux/kernel.h:12,
from ./include/linux/list.h:9,
from ./include/linux/preempt.h:11,
from ./include/linux/spinlock.h:51,
from ./include/linux/seqlock.h:36,
from ./include/linux/time.h:6,
from arch/mips/vdso/vgettimeofday.c:10:
./arch/mips/include/asm/mips-cm.h: In function 'mips_cm_max_vp_width':
./include/linux/bits.h:20:39: warning: right shift count >= width of type
[-Wshift-count-overflow]
(((~0UL) - (1UL << (l)) + 1) & (~0UL >> (BITS_PER_LONG - 1 - (h
^~
./arch/mips/include/asm/mips-cm.h:152:28: note: in expansion of macro 'GENMASK'
#define CM_GCR_REV_MAJOR GENMASK(15, 8)
^~~
./arch/mips/include/asm/mips-cm.h:156:22: note: in expansion of macro
'CM_GCR_REV_MAJOR'
(((major) << __ffs(CM_GCR_REV_MAJOR)) | \
Re: [PATCH v7 00/25] Unify vDSOs across more architectures
On 24/06/2019 15:49, Catalin Marinas wrote: > On Mon, Jun 24, 2019 at 03:23:46PM +0100, Russell King wrote: >> On Mon, Jun 24, 2019 at 04:18:28PM +0200, Thomas Gleixner wrote: >>> Vincenzo, >>> >>> On Mon, 24 Jun 2019, Thomas Gleixner wrote: >>> I did not merge the ARM and MIPS parts as they lack any form of acknowlegment from their maintainers. Please talk to those folks. If they ack/review the changes then I can pick them up and they go into 5.3 or they have to go in a later cycle. Nevertheless it was well worth the trouble to have those conversions done to confirm that the new common library fits a bunch of different architectures. >>> >>> I talked to Russell King and he suggested to file the ARM parts into his >>> patch system and he'll pick them up after 5.3-rc1. >>> >>>https://www.arm.linux.org.uk/developer/patches/ >>> >>> I paged out how to deal with it, but you'll surely manage :) >> >> Easy way: ask git to add the "KernelVersion" tag as a header to the >> email using --add-header to e.g. git format-patch, and just mail them >> to patc...@armlinux.org.uk > > Although I haven't send patches to Russell in a while, I still have a > git alias in my .gitconfig (only works with one patch at a time IIRC, > sending multiple patches may arrive in a different order): > > [alias] > send-rmk-email = !git send-email --add-header=\"KernelVersion: $(git > describe --abbrev=0)\" --no-thread --suppress-cc=all > --to="patc...@arm.linux.org.uk" > Thanks to all for the hints and the support. I will send the patches to Russel as agreed. -- Regards, Vincenzo
Re: [PATCH v7 00/25] Unify vDSOs across more architectures
On Mon, Jun 24, 2019 at 03:23:46PM +0100, Russell King wrote: > On Mon, Jun 24, 2019 at 04:18:28PM +0200, Thomas Gleixner wrote: > > Vincenzo, > > > > On Mon, 24 Jun 2019, Thomas Gleixner wrote: > > > > > I did not merge the ARM and MIPS parts as they lack any form of > > > acknowlegment from their maintainers. Please talk to those folks. If they > > > ack/review the changes then I can pick them up and they go into 5.3 or > > > they > > > have to go in a later cycle. Nevertheless it was well worth the trouble to > > > have those conversions done to confirm that the new common library fits a > > > bunch of different architectures. > > > > I talked to Russell King and he suggested to file the ARM parts into his > > patch system and he'll pick them up after 5.3-rc1. > > > >https://www.arm.linux.org.uk/developer/patches/ > > > > I paged out how to deal with it, but you'll surely manage :) > > Easy way: ask git to add the "KernelVersion" tag as a header to the > email using --add-header to e.g. git format-patch, and just mail them > to patc...@armlinux.org.uk Although I haven't send patches to Russell in a while, I still have a git alias in my .gitconfig (only works with one patch at a time IIRC, sending multiple patches may arrive in a different order): [alias] send-rmk-email = !git send-email --add-header=\"KernelVersion: $(git describe --abbrev=0)\" --no-thread --suppress-cc=all --to="patc...@arm.linux.org.uk" -- Catalin
Re: [PATCH v7 00/25] Unify vDSOs across more architectures
On Mon, Jun 24, 2019 at 04:18:28PM +0200, Thomas Gleixner wrote: > Vincenzo, > > On Mon, 24 Jun 2019, Thomas Gleixner wrote: > > > I did not merge the ARM and MIPS parts as they lack any form of > > acknowlegment from their maintainers. Please talk to those folks. If they > > ack/review the changes then I can pick them up and they go into 5.3 or they > > have to go in a later cycle. Nevertheless it was well worth the trouble to > > have those conversions done to confirm that the new common library fits a > > bunch of different architectures. > > I talked to Russell King and he suggested to file the ARM parts into his > patch system and he'll pick them up after 5.3-rc1. > >https://www.arm.linux.org.uk/developer/patches/ > > I paged out how to deal with it, but you'll surely manage :) Easy way: ask git to add the "KernelVersion" tag as a header to the email using --add-header to e.g. git format-patch, and just mail them to patc...@armlinux.org.uk -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
Re: [PATCH v7 00/25] Unify vDSOs across more architectures
Vincenzo, On Mon, 24 Jun 2019, Thomas Gleixner wrote: > I did not merge the ARM and MIPS parts as they lack any form of > acknowlegment from their maintainers. Please talk to those folks. If they > ack/review the changes then I can pick them up and they go into 5.3 or they > have to go in a later cycle. Nevertheless it was well worth the trouble to > have those conversions done to confirm that the new common library fits a > bunch of different architectures. I talked to Russell King and he suggested to file the ARM parts into his patch system and he'll pick them up after 5.3-rc1. https://www.arm.linux.org.uk/developer/patches/ I paged out how to deal with it, but you'll surely manage :) Thanks, tglx
Re: [PATCH v7 00/25] Unify vDSOs across more architectures
Hi Thomas, On 24/06/2019 01:34, Thomas Gleixner wrote: > Vincenzo, > > On Fri, 21 Jun 2019, Vincenzo Frascino 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. >> >> Even if the mechanism is pretty much standard, every architecture >> in the last few years ended up implementing their own vDSO library >> in the architectural code. > > > >> This implementation contains the portings to the common library for: arm64, >> compat mode for arm64, arm, mips, x86_64, x32, compat mode for x86_64 and >> i386. > > I picked up the core implementation and the ARM64 and x86 conversion. I did > some refinements in several places, coding style, naming conventions, > comments and changelogs including subject prefixes. Please double check! > I tested your changes and they seem OK (git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/vdso). ... > As you can see from the commit dates, this has soaked for some time in a > WIP branch and I did extensive regression testing. So far so good. > > Thanks a lot for going through several iterations. It's a very much > appreciated effort! > It has been a lot of fun and I learned many many things about the vDSOs and the kernel that I did not know before. Thanks to you for your patience and guidance. > Especially with the upcoming time namespaces this will avoid a lot of > duplicated and pointlessly different horrors all over the architecture > space. Any architecture which wants to gain that support needs to convert > to the generic VDSO first. > > As you have become the dude who knows almost everything about VDSO > including all the nasty pitfalls, I propose the patch below. > Thanks for this, it means a lot to me. > Thanks, > > tglx > > 8< > Subject: MAINTAINERS: Add entry for the generic VDSO library > From: Thomas Gleixner > Date: Mon, 24 Jun 2019 02:03:50 +0200 > > Asign the following folks in alphabetic order: > > - Andy for being the VDSO wizard of x86 and in general. He's also the >performance monitor of choice and the code in the generic library is >heavily influenced by his previous x86 VDSO work. > > - Thomas for being the dude who has to deal with any form of time(r) >nonsense anyway > > - Vincenzo for being the poor sod who went through all the different >architecture implementations in order to unify them. A lot of knowledge >gained from VDSO implementation details to the intricacies of taming the >build system. > > Signed-off-by: Thomas Gleixner > --- > MAINTAINERS | 12 > 1 file changed, 12 insertions(+) > > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6665,6 +6665,18 @@ L: k...@vger.kernel.org > S: Supported > F: drivers/uio/uio_pci_generic.c > > +GENERIC VDSO LIBRARY: > +M: Andy Lutomirksy > +M: Thomas Gleixner > +M: Vincenzo Frascino > +L: linux-kernel@vger.kernel.org > +T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > timers/vdso > +S: Maintained > +F: lib/vdso > +F: kernel/time/vsyscall.c > +F: include/vdso > +F: include/asm-generic/vdso/vsyscall.h > + > GENWQE (IBM Generic Workqueue Card) > M: Frank Haverkamp > S: Supported > -- Regards, Vincenzo
Re: [PATCH v7 00/25] Unify vDSOs across more architectures
On Fri, 21 Jun 2019 10:52:27 +0100 Vincenzo Frascino wrote: Hi, > 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. [ ... ] Some numbers for the ARM(32) part: I booted my trusted old Calxeda Midway server (Cortex A-15 cores) and ran the vdsotest benchmark on it. The results are: (vdso: times, in nsec/call; n/t: "not tested" (=not implemented)) call5.2-rc3 5.2-rc3-vdso clock-gettime-monotonic:147 142 clock-getres-monotonic: n/t 34 clock-gettime-monotonic-coarse: 90 96 clock-getres-monotonic-coarse: n/t 36 clock-gettime-monotonic-raw:431 142 clock-getres-monotonic-raw: n/t 35 clock-gettime-tai: 598 150 clock-getres-tai: n/t 34 clock-gettime-boottime: 592 142 clock-getres-boottime: n/t 34 clock-gettime-realtime: 149 142 clock-getres-realtime: n/t 34 clock-gettime-realtime-coarse: 86 96 clock-getres-realtime-coarse: n/t 36 getcpu: n/t n/t gettimeofday: 133 110 So there are some minor improvements, two minor regressions, some significant improvements (factor 3-4), and some dramatic improvements (where we actually gained VDSO support). Overall a pretty impressive outcome for an "Odd fixes" architecture, especially as it should reduce the future maintenance burden. Cheers, Andre.
Re: [PATCH v7 00/25] Unify vDSOs across more architectures
On Sun, 23 Jun 2019, Andy Lutomirski wrote: > On Sun, Jun 23, 2019 at 5:34 PM Thomas Gleixner wrote: > > +GENERIC VDSO LIBRARY: > > +M: Andy Lutomirksy > > Lutomirski, perhaps? Ooops. Where did I copy that from? > Although I do appreciate the opportunity to say "not me!" :) You just gave me the perfect exit plan. I'll change my surname to Gleyxner and head off to the goat farm :) Thanks, tglx
Re: [PATCH v7 00/25] Unify vDSOs across more architectures
Vincenzo, On Fri, 21 Jun 2019, Vincenzo Frascino 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. > > Even if the mechanism is pretty much standard, every architecture > in the last few years ended up implementing their own vDSO library > in the architectural code. > This implementation contains the portings to the common library for: arm64, > compat mode for arm64, arm, mips, x86_64, x32, compat mode for x86_64 and > i386. I picked up the core implementation and the ARM64 and x86 conversion. I did some refinements in several places, coding style, naming conventions, comments and changelogs including subject prefixes. Please double check! I did not merge the ARM and MIPS parts as they lack any form of acknowlegment from their maintainers. Please talk to those folks. If they ack/review the changes then I can pick them up and they go into 5.3 or they have to go in a later cycle. Nevertheless it was well worth the trouble to have those conversions done to confirm that the new common library fits a bunch of different architectures. As you can see from the commit dates, this has soaked for some time in a WIP branch and I did extensive regression testing. So far so good. Thanks a lot for going through several iterations. It's a very much appreciated effort! Especially with the upcoming time namespaces this will avoid a lot of duplicated and pointlessly different horrors all over the architecture space. Any architecture which wants to gain that support needs to convert to the generic VDSO first. As you have become the dude who knows almost everything about VDSO including all the nasty pitfalls, I propose the patch below. Thanks, tglx 8< Subject: MAINTAINERS: Add entry for the generic VDSO library From: Thomas Gleixner Date: Mon, 24 Jun 2019 02:03:50 +0200 Asign the following folks in alphabetic order: - Andy for being the VDSO wizard of x86 and in general. He's also the performance monitor of choice and the code in the generic library is heavily influenced by his previous x86 VDSO work. - Thomas for being the dude who has to deal with any form of time(r) nonsense anyway - Vincenzo for being the poor sod who went through all the different architecture implementations in order to unify them. A lot of knowledge gained from VDSO implementation details to the intricacies of taming the build system. Signed-off-by: Thomas Gleixner --- MAINTAINERS | 12 1 file changed, 12 insertions(+) --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6665,6 +6665,18 @@ L: k...@vger.kernel.org S: Supported F: drivers/uio/uio_pci_generic.c +GENERIC VDSO LIBRARY: +M: Andy Lutomirksy +M: Thomas Gleixner +M: Vincenzo Frascino +L: linux-kernel@vger.kernel.org +T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/vdso +S: Maintained +F: lib/vdso +F: kernel/time/vsyscall.c +F: include/vdso +F: include/asm-generic/vdso/vsyscall.h + GENWQE (IBM Generic Workqueue Card) M: Frank Haverkamp S: Supported
Re: [PATCH v7 00/25] Unify vDSOs across more architectures
On Sun, Jun 23, 2019 at 5:34 PM Thomas Gleixner wrote: > +GENERIC VDSO LIBRARY: > +M: Andy Lutomirksy Lutomirski, perhaps? Although I do appreciate the opportunity to say "not me!" :)
[PATCH v7 00/25] Unify vDSOs across more architectures
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. Even if the mechanism is pretty much standard, every architecture in the last few years ended up implementing their own vDSO library in the architectural code. The purpose of this patch-set is to identify the commonalities in between the architectures and try to consolidate the common code paths, starting with gettimeofday(). This implementation contains the following design choices: * Every architecture defines the arch specific code in an header in "asm/vdso/". * The generic implementation includes the arch specific one and lives in "lib/vdso". * The arch specific code for gettimeofday lives in "/vdso/gettimeofday.c" and includes the generic code only. * The generic implementation of update_vsyscall and update_vsyscall_tz lives in kernel/vdso and provide the bindings that can be implemented by each architecture. * Each architecture provides its implementation of the bindings in "asm/vdso/vsyscall.h". * This approach allows to consolidate the common code in a single place with the benefit of avoiding code duplication. This implementation contains the portings to the common library for: arm64, compat mode for arm64, arm, mips, x86_64, x32, compat mode for x86_64 and i386. The mips porting has been tested on qemu for mips32el. A configuration to repeat the tests can be found at [4]. The x86_64 porting has been tested on an Intel Xeon 5120T based machine running Ubuntu 18.04 and using the Ubuntu provided defconfig. The i386 porting has been tested on qemu using the i386_defconfig configuration. Last but not least from this porting arm64, compat arm64, arm and mips gain the support for: * CLOCK_BOOTTIME that can be useful in certain scenarios since it keeps track of the time during sleep as well. * CLOCK_TAI that is like CLOCK_REALTIME, but uses the International Atomic Time (TAI) reference instead of UTC to avoid jumping on leap second updates. for both clock_gettime and clock_getres. The porting has been validated using the vdsotest test-suite [1] extended to cover all the clock ids [2]. A new test has been added to the linux kselftest in order to validate the newly added library. The porting has been benchmarked and the performance results are provided as part of this cover letter. To simplify the testing, a copy of the patchset on top of a recent linux tree can be found at [3] and [4]. The v7 of this patchseries has been rebased on [5]. [1] https://github.com/nathanlynch/vdsotest [2] https://github.com/fvincenzo/vdsotest [3] git://linux-arm.org/linux-vf.git vdso/v7 [4] git://linux-arm.org/linux-vf.git vdso-mips/v7 [5] git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git hyperv-next Changes: v7: - Rebased on [5] (5.2-rc3). - Added performance numbers for arm64 provided by Shijith Thotton. - Aimed at 1:1 replacement for pre-exisiting vDSO libraries. - Provided separate patches for newly added API. - Addressed review comments. v6: - Rebased on 5.2-rc2. - Added performance numbers. - Removed vdso_types.h. - Unified update_vsyscall and update_vsyscall_tz. - Reworked the kselftest included in this patchset. - Addressed review comments. v5: - Rebased on 5.0-rc7. - Added x86_64, compat mode for x86_64 and i386 portings. - Extended vDSO kselftest. - Addressed review comments. v4: - Rebased on 5.0-rc2. - Addressed review comments. - Disabled compat vdso on arm64 when the kernel is compiled with clang. v3: - Ported the latest fixes and optimizations done on the x86 architecture to the generic library. - Addressed review comments. - Improved the documentation of the interfaces. - Changed the HAVE_ARCH_TIMER config option to a more generic HAVE_HW_COUNTER. v2: - Added -ffixed-x18 to arm64 - Repleced occurrences of timeval and timespec - Modified datapage.h to be compliant with y2038 on all the architectures - Removed __u_vdso type Cc: Catalin Marinas Cc: Will Deacon Cc: Arnd Bergmann Cc: Russell King Cc: Ralf Baechle Cc: Paul Burton Cc: Daniel Lezcano Cc: Thomas Gleixner Cc: Mark Salyzyn Cc: Peter Collingbourne Cc: Shuah Khan Cc: Dmitry Safonov <0x7f454...@gmail.com> Cc: Rasmus Villemoes Cc: Huw Davies Cc: Shijith Thotton Cc: Andre Przywara Signed-off-by: Vincenzo Frascino Tested-by: Shijith Thotton Tested-by: Andre Przywara Performance Numbers: Linux 5.2.0-rc2 - Xeon Gold 5120T == Unified vDSO: - clock-gettime-monotonic: syscall: 342 nsec/call clock-gettime-monotonic:libc: 25 nsec/call clock-gettime-monotonic:
