This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 6/6] aarch64: Add hp-timing.h
- From: Richard Henderson <rth at twiddle dot net>
- To: Catalin Marinas <catalin dot marinas at arm dot com>, Marcus Shawcroft <marcus dot shawcroft at gmail dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, Carlos O'Donell <carlos at redhat dot com>, Andreas Schwab <schwab at suse dot de>, "azanella at linux dot vnet dot ibm dot com" <azanella at linux dot vnet dot ibm dot com>, "davem at davemloft dot net" <davem at davemloft dot net>, "marcus dot shawcroft at arm dot com" <marcus dot shawcroft at arm dot com>, Andrew Pinski <pinskia at gmail dot com>, peter dot maydell at linaro dot org, Szabolcs dot Nagy at arm dot com
- Date: Wed, 9 Sep 2015 17:33:23 -0700
- Subject: Re: [PATCH 6/6] aarch64: Add hp-timing.h
- Authentication-results: sourceware.org; auth=none
- References: <1403735086-21797-1-git-send-email-rth at twiddle dot net> <1403735086-21797-7-git-send-email-rth at twiddle dot net> <mvmd2czlz0k dot fsf at hawking dot suse dot de> <812AFAEE-C8E5-4583-8647-7E5ABE02F95C at gmail dot com> <mvm4myanco3 dot fsf at hawking dot suse dot de> <CAFqB+PyCXom3fqF8A=C10jV9syUeRmOg-JuTL1pxtVnLsgfj7A at mail dot gmail dot com> <55861F56 dot 1030506 at redhat dot com> <89431F96-326C-4054-B2D6-17863543CC9B at gmail dot com> <CA+=Sn1kZL8xmCPtzpULRMNQ7ommN6FxRmAQJVy2LV+wOF+WSkQ at mail dot gmail dot com> <CAFqB+PzWoxrDfM8FYRBQq2+JZruoveB_xiTEH+edOBLaOxW7qw at mail dot gmail dot com> <20150909111434 dot GC17828 at localhost>
On 09/09/2015 04:14 AM, Catalin Marinas wrote:
What are the glibc expectations here for HP_TIMING? Is it fine if it
always returns 0? Does its frequency need to be known? If yes, how do we
expose such frequency to user space?
Yes it's fine if it returns 0. You just won't get useful timing info when
using LD_DEBUG=statistics.
No, we don't require a known frequency. Even on x86 we simply print "cycles"
rather than a scaled time.
I think the only real requirement is not crashing due to sigill while
collecting the statistics. ;-)
IIUC here it's a simple HP_TIMING_NOW macro which translates to an mrs.
I did that simply because it worked for me. You'll notice the significant
push-back that patch elicited. ;-)
Do you plan to add further checks for HWCAP here?
If required. It ought to be easy.
Is exposing a reader function via VDSO be feasible here? Or it's too
early for the dynamic loader?
Good question... it's on the edge, right after self-relocation of ld.so, but
before proper relocation of libc and re-relocation of ld.so (e.g. to use libc
symbols like malloc instead of the bootstrapping stubs).
Finding the VDSO is certainly easy, since its pointer is in auxv, and we will
have stored that. But how much effort it is to look up a symbol by name for
that at that point in the bootstrap, I don't know.
Would the kernel be likely to provide an implementation that wasn't simply the
mrs insn?
If not, I don't know that's any better than the HWCAP bit. Either way we need
a test-and-branch. Whether that's checking for a null pointer because the
kernel didn't provide the vdso entry point, or checking hwcap for the bit, it's
just about the same.
r~