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: Catalin Marinas <catalin dot marinas at arm dot com>
- To: Richard Henderson <rth at twiddle dot net>
- Cc: Marcus Shawcroft <marcus dot shawcroft at gmail dot com>, "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: Fri, 11 Sep 2015 14:14:18 +0100
- Subject: Re: [PATCH 6/6] aarch64: Add hp-timing.h
- Authentication-results: sourceware.org; auth=none
- References: <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> <55F0CFD3 dot 8060102 at twiddle dot net>
On Wed, Sep 09, 2015 at 05:33:23PM -0700, Richard Henderson wrote:
> 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.
Let's start with a HWCAP bit. But someone needs to write a patch and
post it on linux-arm-kernel ;) (being an ABI request, it needs raising
it on the kernel list).
--
Catalin