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

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

On 11/02/2019 11:22, Carlos O'Donell wrote:
> On 2/11/19 7:54 AM, Florian Weimer wrote:
>> * Adhemerval Zanella:
>>
>>> On 11/02/2019 09:43, Florian Weimer wrote:
>>>> * Adhemerval Zanella:
>>>>
>>>>> 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...
>>>>
>>>> Are you sure about that?  Wouldn't that be a bug in kernel
>>>> clock_gettime, and not something we should paper over in userspace?
>>>
>>> Not sure, I was just my impression checking kernel ia64 code but I am
>>> not an architecture expert. To be safe I kept the original code in
>>> patch proposal.
>>
>> I think it's not worth maintaing the ia64 divergence for this.  If it is
>> a problem with the kernel's CLOCK_MONOTONIC implementation, it has to be
>> fixed there.
> 
> I tend to agree. Standard interfaces should behave in standard ways.
> 
> We have the same problem in HPPA where a similar clock (and my feeling was
> always that IA64 derived a lot from HP PARISC 64-bit) that needs synchronization
> at SMP rendevous at boot time, followed by bias and drift adjustment.
> 
> For HPPA we made sue that the everything was accurately compensated at the
> kernel timer source level, and never in userspace. You *can* do it in userspace
> and it's faster and lower latency, and all of those things, but it's more complex
> and prone to breakage for odd reasons (compiler optimizations etc.).
> 
> For HPPA you can access the tick counter in userspace, raw, and it's
> useful for timing small sequences of code, but if you move to a new CPU
> mid-measurement, you'll get wrong values because the value and bias is per-cpu.
> 

Alright, I will refactor it to remove ia64 idiosyncrasies.