This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


* 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]