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

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 09/02/2019 08:35, Florian Weimer wrote:
> * 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?

I am not sure, the information I am gathering indicates taht processors with 
ITC drift still requires user adjustments according to IA64 manual:

"The interval counter can be written, for initialization purposes, by
privileged code. The ITC is not architecturally guaranteed to be
synchronized with any other processor's interval time counter in a 
multi-processor system, nor is it synchronized with the wall clock.
*Software must calibrate interval timer ticks to wall clock time and
periodically adjust for drift." (3.3.4.2 page 3-15) [1].

Also Linux code has these two comments:

arch/ia64/kernel/time.c
283 #ifdef CONFIG_SMP
284                 /* On IA64 in an SMP configuration ITCs are never accurately synchronized.
285                  * Jitter compensation requires a cmpxchg which may limit
286                  * the scalability of the syscalls for retrieving time.
287                  * The ITC synchronization is usually successful to within a few
288                  * ITC ticks but this is not a sure thing. If you need to improve
289                  * timer performance in SMP situations then boot the kernel with the
290                  * "nojitter" option. However, doing so may result in time fluctuating (maybe
291                  * even going backward) if the ITC offsets between the individual CPUs
292                  * are too large.
293                  */
294                 if (!nojitter)
295                         itc_jitter_data.itc_jitter = 1;
296 #endif
297         } else
298                 /*
299                  * ITC is drifty and we have not synchronized the ITCs in smpboot.c.
300                  * ITC values may fluctuate significantly between processors.
301                  * Clock should not be used for hrtimers. Mark itc as only
302                  * useful for boot and testing.
303                  *
304                  * Note that jitter compensation is off! There is no point of
305                  * synchronizing ITCs since they may be large differentials
306                  * that change over time.
307                  *
308                  * The only way to fix this would be to repeatedly sync the
309                  * ITCs. Until that time we have to avoid ITC.
310                  */
311                 clocksource_itc.rating = 50;

So taking in consideration that kernel still thinks it is important to
explicit export '/proc/sal/itc_drift' and the fact that clock_gettime
ia syscall implementation (arch/ia64/kernel/fsys.S) uses a quite complex
code to adjust the timer code using itc jitter timer reference, I think
it is still relevant for some IA64 chips that does not have itc_drift
as '1' (ITC may drift).

The Itanium system I have access, Itanium 2 9020, does not have ITC drift
so I can't really tell how it plays on syscalls.  Also I am not sure how
common is systems with ITC that may drift.

> 
> 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.

I think the word here is not 'wrong', but rather 'inaccurate'.  I still
think it provides valuable profiling data about loader's work (assuming
loader work does not overflow the counter itself, as we do for alpha).

> 
> 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.

nscd uses _SC_MONOTONIC_CLOCK and if I understood correctly both IA64 
manual and kernel code, the CLOCK_MONOTONIC implementation on SMP IA64
system with ITC that may drift is a best effort...

> 
> Thanks,
> Florian
> 

[1] http://refspecs.linux-foundation.org/IA64-softdevman-vol2.pdf