From: Carlos O'Donell <carlos@redhat.com>
To: "H.J. Lu" <hjl.tools@gmail.com>, Florian Weimer <fweimer@redhat.com>
Cc: Alexander Monakov via Libc-alpha <libc-alpha@sourceware.org>
Subject: Re: V2 [PATCH] benchtests: Restore the clock_gettime option
Date: Thu, 4 Jun 2020 17:24:48 -0400 [thread overview]
Message-ID: <0760154d-f681-ae5d-2147-e4d1d6e0cb09@redhat.com> (raw)
In-Reply-To: <CAMe9rOp7EdV2NPzq0Tz-GKNtf=WpTyvaL9anA8-dTufa-CS-tQ@mail.gmail.com>
On 5/20/20 2:14 PM, H.J. Lu via Libc-alpha wrote:
> On Wed, May 20, 2020 at 11:05 AM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * Alexander Monakov via Libc-alpha:
>>
>>> I am well aware. Again: rdtsc does not count CPU cycles on recent
>>> Intel CPUs.
>>
>> H.J. probably has a different view on what those “recent Intel CPUs”
>> are. 8-) I have not reviewed the mechanics of the patch, but if we need
>> this for some CPUs, we should make the change.
>>
>
> Here the patch with updated commit message:
>
> commit 7621e38bf3c58b2d0359545f1f2898017fd89d05
> Author: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
> Date: Tue Jan 29 17:43:45 2019 +0000
>
> Add generic hp-timing support
>
> removed the clock_gettime option. Restore the clock_gettime option for
> some x86 CPUs on which value from RDTSC may not be incremented at a fixed
> rate.
>
> OK for master?
OK for master.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
> Thanks.
>
> From 7e48f7adbd53c18df7ab5fdd488bfcc134627480 Mon Sep 17 00:00:00 2001
> From: "H.J. Lu" <hjl.tools@gmail.com>
> Date: Mon, 18 May 2020 17:28:42 -0700
> Subject: [PATCH] benchtests: Restore the clock_gettime option
>
> commit 7621e38bf3c58b2d0359545f1f2898017fd89d05
> Author: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
> Date: Tue Jan 29 17:43:45 2019 +0000
>
> Add generic hp-timing support
>
> removed the clock_gettime option. Restore the clock_gettime option for
> some x86 CPUs on which value from RDTSC may not be incremented at a fixed
> rate.
> ---
> benchtests/Makefile | 6 ++++++
> benchtests/README | 7 ++++++-
> benchtests/bench-timing.h | 6 +++++-
> 3 files changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/benchtests/Makefile b/benchtests/Makefile
> index 335d643ecb..99e90d17a0 100644
> --- a/benchtests/Makefile
> +++ b/benchtests/Makefile
> @@ -132,11 +132,17 @@ endif
>
> CPPFLAGS-nonlib += -DDURATION=$(BENCH_DURATION) -D_ISOMAC
>
> +# Use clock_gettime to measure performance of functions. The default is
> +# to use the architecture-specific high precision timing instructions.
> +ifdef USE_CLOCK_GETTIME
> +CPPFLAGS-nonlib += -DUSE_CLOCK_GETTIME
> +else
> # On x86 processors, use RDTSCP, instead of RDTSC, to measure performance
> # of functions. All x86 processors since 2010 support RDTSCP instruction.
> ifdef USE_RDTSCP
> CPPFLAGS-nonlib += -DUSE_RDTSCP
> endif
> +endif
>
> DETAILED_OPT :=
>
> diff --git a/benchtests/README b/benchtests/README
> index c4f03fd872..f440f3295a 100644
> --- a/benchtests/README
> +++ b/benchtests/README
> @@ -27,7 +27,12 @@ BENCH_DURATION.
>
> The benchmark suite does function call measurements using architecture-specific
> high precision timing instructions whenever available. When such support is
> -not available, it uses clock_gettime (CLOCK_MONOTONIC).
> +not available, it uses clock_gettime (CLOCK_MONOTONIC). One can force the
> +benchmark to use clock_gettime by invoking make as follows:
> +
> + $ make USE_CLOCK_GETTIME=1 bench
> +
> +Again, one must run `make bench-clean' before changing the measurement method.
>
> On x86 processors, RDTSCP instruction provides more precise timing data
> than RDTSC instruction. All x86 processors since 2010 support RDTSCP
> diff --git a/benchtests/bench-timing.h b/benchtests/bench-timing.h
> index 5b9a8384bb..844a7727c9 100644
> --- a/benchtests/bench-timing.h
> +++ b/benchtests/bench-timing.h
> @@ -19,7 +19,11 @@
> #undef attribute_hidden
> #define attribute_hidden
> #define __clock_gettime clock_gettime
> -#include <hp-timing.h>
> +#ifdef USE_CLOCK_GETTIME
> +# include <sysdeps/generic/hp-timing.h>
> +#else
> +# include <hp-timing.h>
> +#endif
> #include <stdint.h>
>
> #define GL(x) _##x
> --
> 2.26.2
>
--
Cheers,
Carlos.
prev parent reply other threads:[~2020-06-04 21:24 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-19 20:30 H.J. Lu
2020-05-19 21:18 ` Alexander Monakov
2020-05-19 21:45 ` H.J. Lu
2020-05-19 22:16 ` Alexander Monakov
2020-05-20 17:51 ` H.J. Lu
2020-05-20 18:01 ` Alexander Monakov
2020-05-20 18:05 ` Florian Weimer
2020-05-20 18:14 ` V2 " H.J. Lu
2020-05-20 18:17 ` Florian Weimer
2020-05-20 18:18 ` Adhemerval Zanella
2020-05-20 18:52 ` H.J. Lu
2020-06-04 21:24 ` Carlos O'Donell [this message]
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=0760154d-f681-ae5d-2147-e4d1d6e0cb09@redhat.com \
--to=carlos@redhat.com \
--cc=fweimer@redhat.com \
--cc=hjl.tools@gmail.com \
--cc=libc-alpha@sourceware.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 read-only IMAP folder(s) and NNTP newsgroup(s).