[erlang-questions] Fwd: erlang:trace/3 and cpu_timestamp

[mats cronqvist]

  man clock_gettime says;
"The  CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID clocks are
realized on many platforms using timers from the CPUs  (TSC on i386,
AR.ITC  on Itanium). These  registers  may differ between CPUs and as a
consequence these clocks may return bogus results if a process is migrated
to  another CPU."

  Assuming that this is what you refer to, it seems wrong to disable
cpu_timestamp on Linux. E.g., what if I run on a single-core machine? Or if
my hardware is modern enough to support cross-core synchronized TSC?

  Also, that man page seems to be from 2007. It doesn't seem inconceivable
that the kernel has grown features since then.

  So, OTP has disabled cpu_timestamp on all Linux machines, because it
might give bad data on some hardware/kernel combinations. I would be
happier if I could decide myself if I want to trust the data or not.


On Thu, Apr 24, 2014 at 4:17 PM, Lukas Larsson <lukas@REDACTED> wrote:

> Hello,
>
> The cpu_timestamp functionality needs the timestamp to be monotonic across
> cpus which the linux version of clock_gettime(CLOCK_PROCESS_CPUTIME_ID,_)
> isn't. This is why it is disabled on Linux.
>
> Lukas
>
>
> On Thu, Apr 24, 2014 at 10:56 AM, mats cronqvist <masse@REDACTED> wrote:
>
>>
>>   tracing with high-resolution timers doesn't seem to work un my linux
>> boxes (centos6, in this case);
>>
>> 247> erlang:trace(all,true,[call,cpu_timestamp]).
>> ** exception error: bad argument
>>      in function  erlang:trace/3
>>         called as erlang:trace(all,true,[call,cpu_timestamp])
>>
>>   Seemingly, this is because this check in aclocal.m4;
>>
>>    case $host_os in
>>        linux*)
>>            AC_MSG_RESULT([no; not stable])
>>            LIBRT=$xrtlib
>>            ;;
>>
>>   Indeed, commenting out the above and rebuilding beam works;
>>
>> 1> erlang:trace(all,true,[call,cpu_timestamp]).
>> 24
>>
>>   Is there any reason not to enable this?
>>
>>   mats
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140425/64fe6b5f/attachment.htm>