[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