linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	Paul Mackerras <paulus@samba.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: [PATCH v3 2/8] powerpc/vdso32: Add support for CLOCK_{REALTIME/MONOTONIC}_COARSE
Date: Thu, 21 Nov 2019 10:53:54 +1100	[thread overview]
Message-ID: <87blt6ayul.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <20191120161741.Horde.zNDnbMKk_BJpkUOkWeRMsQ1@messagerie.si.c-s.fr>

Christophe Leroy <christophe.leroy@c-s.fr> writes:
> Michael Ellerman <mpe@ellerman.id.au> a écrit :
>> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>>> This is copied and adapted from commit 5c929885f1bb ("powerpc/vdso64:
>>> Add support for CLOCK_{REALTIME/MONOTONIC}_COARSE")
>>> from Santosh Sivaraj <santosh@fossix.org>
>>>
>>> Benchmark from vdsotest-all:
>>> clock-gettime-realtime: syscall: 3601 nsec/call
>>> clock-gettime-realtime:    libc: 1072 nsec/call
>>> clock-gettime-realtime:    vdso: 931 nsec/call
>>> clock-gettime-monotonic: syscall: 4034 nsec/call
>>> clock-gettime-monotonic:    libc: 1213 nsec/call
>>> clock-gettime-monotonic:    vdso: 1076 nsec/call
>>> clock-gettime-realtime-coarse: syscall: 2722 nsec/call
>>> clock-gettime-realtime-coarse:    libc: 805 nsec/call
>>> clock-gettime-realtime-coarse:    vdso: 668 nsec/call
>>> clock-gettime-monotonic-coarse: syscall: 2949 nsec/call
>>> clock-gettime-monotonic-coarse:    libc: 882 nsec/call
>>> clock-gettime-monotonic-coarse:    vdso: 745 nsec/call
>>>
>>> Additional test passed with:
>>> 	vdsotest -d 30 clock-gettime-monotonic-coarse verify
>>
>> This broke on 64-bit big endian, which uses the 32-bit VDSO, with errors
>> like:
>>
>>   clock-gettime-monotonic-coarse/verify: 10 failures/inconsistencies  
>> encountered
>>   timestamp obtained from libc/vDSO not normalized:
>>   	[-1574202155, 1061008673]
>>   timestamp obtained from libc/vDSO predates timestamp
>>   previously obtained from kernel:
>>   	[74, 261310747] (kernel)
>>   	[-1574202155, 1061008673] (vDSO)
>>   timestamp obtained from libc/vDSO not normalized:
>>   	[-1574202155, 1061008673]
>>   timestamp obtained from libc/vDSO predates timestamp
>>   previously obtained from kernel:
>>   	[74, 261310747] (kernel)
>>   	[-1574202155, 1061008673] (vDSO)
>>   timestamp obtained from libc/vDSO not normalized:
>>   	[-1574202155, 1061008673]
>>   timestamp obtained from libc/vDSO predates timestamp
>>   previously obtained from kernel:
>>   	[74, 261310747] (kernel)
>>   	[-1574202155, 1061008673] (vDSO)
>>   timestamp obtained from libc/vDSO not normalized:
>>   	[-1574202155, 1061008673]
>>   timestamp obtained from libc/vDSO predates timestamp
>>   previously obtained from kernel:
>>   	[74, 261310747] (kernel)
>>   	[-1574202155, 1061008673] (vDSO)
>>   timestamp obtained from libc/vDSO not normalized:
>>   	[-1574202155, 1061008673]
>>   timestamp obtained from libc/vDSO predates timestamp
>>   previously obtained from kernel:
>>   	[74, 261310747] (kernel)
>>   	[-1574202155, 1061008673] (vDSO)
>>   Failure threshold (10) reached; stopping test.
>>
>>
>> The diff below seems to fix it, but I'm not sure it's correct. ie. we
>> just ignore the top part of the values, how does that work?
>
> Your change makes sense, it is consistent with other functions using  
> STAMP_XTIME.
>
> It works because nanoseconds are max 999999999, it fits 32 bits regs.

Yeah, but for seconds? I guess this is the whole Y2038 problem, though
I'm not clear how it's going to work for compat.

Anyway I'll squash that in and get this merged.

cheers

  reply	other threads:[~2019-11-20 23:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-29  9:53 [PATCH v3 0/8] powerpc/vdso32 enhancement and optimisation Christophe Leroy
2019-10-29  9:53 ` [PATCH v3 1/8] powerpc/32: Add VDSO version of getcpu on non SMP Christophe Leroy
2019-10-29  9:53 ` [PATCH v3 2/8] powerpc/vdso32: Add support for CLOCK_{REALTIME/MONOTONIC}_COARSE Christophe Leroy
2019-11-20 12:42   ` Michael Ellerman
2019-11-20 15:17     ` Christophe Leroy
2019-11-20 23:53       ` Michael Ellerman [this message]
2019-10-29  9:53 ` [PATCH v3 3/8] powerpc: Fix vDSO clock_getres() Christophe Leroy
2019-10-29  9:53 ` [PATCH v3 4/8] powerpc/vdso32: inline __get_datapage() Christophe Leroy
2019-11-22  1:58   ` Michael Ellerman
2019-11-22  6:38     ` Michael Ellerman
2019-11-27 14:47       ` Christophe Leroy
2019-11-28  5:31         ` Michael Ellerman
2019-12-02  8:02           ` Christophe Leroy
2019-10-29  9:53 ` [PATCH v3 5/8] powerpc/vdso32: Don't read cache line size from the datapage on PPC32 Christophe Leroy
2019-10-29  9:53 ` [PATCH v3 6/8] powerpc/vdso32: use LOAD_REG_IMMEDIATE() Christophe Leroy
2019-10-29  9:53 ` [PATCH v3 7/8] powerpc/vdso32: implement clock_getres entirely Christophe Leroy
2019-10-29  9:53 ` [PATCH v3 8/8] powerpc/vdso32: miscellaneous optimisations Christophe Leroy

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=87blt6ayul.fsf@mpe.ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=benh@kernel.crashing.org \
    --cc=christophe.leroy@c-s.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=paulus@samba.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: link
Be 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).