[erlang-questions] Fwd: erlang:trace/3 and cpu_timestamp
Fri Apr 25 12:35:17 CEST 2014
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:
> 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.
> 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
>> AC_MSG_RESULT([no; not stable])
>> Indeed, commenting out the above and rebuilding beam works;
>> 1> erlang:trace(all,true,[call,cpu_timestamp]).
>> Is there any reason not to enable this?
>> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions