[PATCH 6/6] aarch64: Add hp-timing.h

Richard Henderson rth@twiddle.net
Thu Sep 10 00:33:00 GMT 2015


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~



More information about the Libc-alpha mailing list