unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
* Loss of vDSO support on s390x
@ 2020-01-15  9:50 Florian Weimer
  2020-01-15 11:31 ` Siddhesh Poyarekar
  0 siblings, 1 reply; 5+ messages in thread
From: Florian Weimer @ 2020-01-15  9:50 UTC (permalink / raw)
  To: libc-alpha

time, gettimeofday, and clock_gettime always seem to make system calls
now.

Is this intentional?  I'm worried that this is a major performance
regression.

Thanks,
Florian


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Loss of vDSO support on s390x
  2020-01-15  9:50 Loss of vDSO support on s390x Florian Weimer
@ 2020-01-15 11:31 ` Siddhesh Poyarekar
  2020-01-15 12:37   ` Florian Weimer
  0 siblings, 1 reply; 5+ messages in thread
From: Siddhesh Poyarekar @ 2020-01-15 11:31 UTC (permalink / raw)
  To: Florian Weimer, libc-alpha, Adhemerval Zanella

On 15/01/20 3:20 pm, Florian Weimer wrote:
> time, gettimeofday, and clock_gettime always seem to make system calls
> now.
> 
> Is this intentional?  I'm worried that this is a major performance
> regression.

+Adhemerval; this may be related to the vDSO patchset.

Siddhesh

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Loss of vDSO support on s390x
  2020-01-15 11:31 ` Siddhesh Poyarekar
@ 2020-01-15 12:37   ` Florian Weimer
  2020-01-15 14:47     ` Stefan Liebler
  0 siblings, 1 reply; 5+ messages in thread
From: Florian Weimer @ 2020-01-15 12:37 UTC (permalink / raw)
  To: Siddhesh Poyarekar; +Cc: libc-alpha, Adhemerval Zanella

* Siddhesh Poyarekar:

> On 15/01/20 3:20 pm, Florian Weimer wrote:
>> time, gettimeofday, and clock_gettime always seem to make system calls
>> now.
>> 
>> Is this intentional?  I'm worried that this is a major performance
>> regression.
>
> +Adhemerval; this may be related to the vDSO patchset.

The kernel I used disables the vDSO with an explicit loader invocation.
I assume this was fixed with this commit:

commit 404861e15b5fa7edbab22400f9174c1a21fde731
Author: Heiko Carstens <heiko.carstens@de.ibm.com>
Date:   Wed Aug 7 14:31:59 2019 +0200

    s390/vdso: map vdso also for statically linked binaries
    
    s390 does not map the vdso for statically linked binaries, assuming
    that this doesn't make sense. See commit fc5243d98ac2 ("[S390]
    arch_setup_additional_pages arguments").
    
    However with glibc commit d665367f596d ("linux: Enable vDSO for static
    linking as default (BZ#19767)") and commit 5e855c895401 ("s390: Enable
    VDSO for static linking") the vdso is also used for statically linked
    binaries - if the kernel would make it available.
    
    Therefore map the vdso always, just like all other architectures.

If I fix this, by hardcoding the new loader, I only see a system call
for the time emulation.  It looks like the vDSO does not have
acceleration for CLOCK_REALTIME_COARSE, which is used by the time
emulation.

I still think this needs to be fixed.

Thanks,
Florian


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Loss of vDSO support on s390x
  2020-01-15 12:37   ` Florian Weimer
@ 2020-01-15 14:47     ` Stefan Liebler
  2020-01-15 15:31       ` Florian Weimer
  0 siblings, 1 reply; 5+ messages in thread
From: Stefan Liebler @ 2020-01-15 14:47 UTC (permalink / raw)
  To: libc-alpha

On 1/15/20 1:37 PM, Florian Weimer wrote:
> * Siddhesh Poyarekar:
> 
>> On 15/01/20 3:20 pm, Florian Weimer wrote:
>>> time, gettimeofday, and clock_gettime always seem to make system calls
>>> now.
>>>
>>> Is this intentional?  I'm worried that this is a major performance
>>> regression. >>
>> +Adhemerval; this may be related to the vDSO patchset.
> 
> The kernel I used disables the vDSO with an explicit loader invocation.
> I assume this was fixed with this commit:
> 
> commit 404861e15b5fa7edbab22400f9174c1a21fde731
> Author: Heiko Carstens <heiko.carstens@de.ibm.com>
> Date:   Wed Aug 7 14:31:59 2019 +0200
> 
>      s390/vdso: map vdso also for statically linked binaries
>      
>      s390 does not map the vdso for statically linked binaries, assuming
>      that this doesn't make sense. See commit fc5243d98ac2 ("[S390]
>      arch_setup_additional_pages arguments").
>      
>      However with glibc commit d665367f596d ("linux: Enable vDSO for static
>      linking as default (BZ#19767)") and commit 5e855c895401 ("s390: Enable
>      VDSO for static linking") the vdso is also used for statically linked
>      binaries - if the kernel would make it available.
>      
>      Therefore map the vdso always, just like all other architectures.
> 
> If I fix this, by hardcoding the new loader, I only see a system call
> for the time emulation.  It looks like the vDSO does not have
> acceleration for CLOCK_REALTIME_COARSE, which is used by the time
> emulation.
According to <kernel>/arch/s390/kernel/vdso64/clock_gettime.S there is 
support for:
- CLOCK_MONOTONIC
- CLOCK_MONOTONIC_COARSE
- CLOCK_REALTIME_COARSE
- CLOCK_REALTIME
- CPUCLOCK_VIRT for this thread
(See 
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/tree/arch/s390/kernel/vdso64/clock_gettime.S?id=2115fbf7210bd053ba55a95e7ebc366df41aa9cf)

> 
> I still think this needs to be fixed.
> 
> Thanks,
> Florian
> 

Do you run on s390x (64bit) or s390 (31bit)?
Heiko has also removed the vdso for 31bit in linux 5.5:
"s390: remove compat vdso code"
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=2115fbf7210bd053ba55a95e7ebc366df41aa9cf

Please double check if the vdso is mapped and the address is passed via 
AT_SYSINFO_EHDR. I've just run a test program linked against current 
glibc and stepped to the vdso.

But on 31bit, the vdso is mapped, but I end in a syscall as my used 
kernel has support for __NR_clock_gettime64 but has no support for 
HAVE_CLOCK_GETTIME64_VSYSCALL (only for HAVE_CLOCK_GETTIME_VSYSCALL).

Bye,
Stefan


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Loss of vDSO support on s390x
  2020-01-15 14:47     ` Stefan Liebler
@ 2020-01-15 15:31       ` Florian Weimer
  0 siblings, 0 replies; 5+ messages in thread
From: Florian Weimer @ 2020-01-15 15:31 UTC (permalink / raw)
  To: Stefan Liebler; +Cc: libc-alpha

* Stefan Liebler:

> According to <kernel>/arch/s390/kernel/vdso64/clock_gettime.S there is
> support for:
> - CLOCK_MONOTONIC
> - CLOCK_MONOTONIC_COARSE
> - CLOCK_REALTIME_COARSE
> - CLOCK_REALTIME
> - CPUCLOCK_VIRT for this thread
> (See
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/tree/arch/s390/kernel/vdso64/clock_gettime.S?id=2115fbf7210bd053ba55a95e7ebc366df41aa9cf)

Hmm.  Looks like I'm missing this kernel commit:

commit b7eacb59cd7fb5e98852186e485c0c865f862645
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date:   Fri Aug 29 12:31:45 2014 +0200

    s390/vdso: add vdso support for coarse clocks
    
    Add CLOCK_REALTIME_COARSE and CLOCK_MONOTONIC_COARSE optimization to
    the 64-bit and 31-bit vdso.

That went into 3.18, so maybe that's old enough.  It will impact people
who run newer containers on el7 hosts, though.  Maybe we should request
a backport of that commit?

> Do you run on s390x (64bit) or s390 (31bit)?

It's s390x.  I expect s390 to be worse (as you showed), but I'm not sure
if we need to fix it proactively.

Thanks,
Florian


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2020-01-15 15:32 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-15  9:50 Loss of vDSO support on s390x Florian Weimer
2020-01-15 11:31 ` Siddhesh Poyarekar
2020-01-15 12:37   ` Florian Weimer
2020-01-15 14:47     ` Stefan Liebler
2020-01-15 15:31       ` Florian Weimer

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 read-only IMAP folder(s) and NNTP newsgroup(s).