[PATCH 2/6] linux: Assume clock_getres CLOCK_{PROCESS,THREAD}_CPUTIME_ID

Florian Weimer fweimer@redhat.com
Sat Feb 9 10:35:00 GMT 2019


* Adhemerval Zanella:

> This patch assumes that clock_getres syscall always support
> CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID, so there is no need
> to fallback to hp-timing support for _SC_MONOTONIC_CLOCK.  This allows
> simplify the sysconf support to always use the syscall.
>
> The ia64 implementation is also simplified and consolidate in one
> file.

Is the ia64-specific implementation really needed?

My impression is that we plan to use CPU-internal timing (such as RDTSC
on x86) in the dynamic linker even if it will produce wrong results.  I
don't like this, but I don't feel strongly about this.

But this means that nothing actually needs the information whether
CPU-internal timing on ia64 is accurate.  If there is a kernel vDSO that
uses the CPU counters for CLOCK_MONOTONIC or CLOCK_MONOTONIC_RAW, then
it's the job of the kernel to ensure that only avoids the syscall if the
counters are accurate.

Thanks,
Florian



More information about the Libc-alpha mailing list