[erlang-questions] is Linux's clock_gettime still "not stable" enough for Erlang?
Adam Kocoloski
disabled on Linux. configure spits out
> checking if clock_gettime can be used to get process CPU time... not
> stable, disabled
and in aclocal.m4 I see
> case $host_os in
> linux*)
> AC_MSG_RESULT([not stable, disabled])
> LIBRT=$xrtlib
> ;;
> *)
I'm wondering what the rationale was behind that, and in particular
whether newer kernels might have fixed the problem. Does anyone
around here know a little more of the backstory? Best,
Adam
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
mats cronqvist
> Hi, it seems to me that cpu_timestamp tracing is automatically
> disabled on Linux. configure spits out
>
>> checking if clock_gettime can be used to get process CPU time... not
>> stable, disabled
>
> and in aclocal.m4 I see
>
>> case $host_os in
>> linux*)
>> AC_MSG_RESULT([not stable, disabled])
>> LIBRT=$xrtlib
>> ;;
>> *)
>
> I'm wondering what the rationale was behind that, and in particular
> whether newer kernels might have fixed the problem. Does anyone
> around here know a little more of the backstory? Best,
I'm not really familiar with this, so the following is at best partly
right.
configure checks for a syscall;
http://www.linuxhowtos.org/manpages/2/clock_gettime.htm
On linuxen, this needs support from hardware, the kernel and libc.
E.g. on debian, with a 2.6 kernel, on i686 HW, you need to install
libc6-i686. That will give you a variant of clock_gettime that is
deemed "stable" by configure.
mats
Joe Williams
clock_gettime and it compiles and seems to work properly. But when I
configure Erlang it complains of it being unstable. I have tried a
couple things to hack around it and force it to be enabled but it didn't
seem to work. Any suggestions on this would be helpful.
Thanks.
-Joe
--
Name: Joseph A. Williams
Email: j...@joetify.com
Blog: http://www.joeandmotorboat.com/
Joe Williams
CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID are supported on
"sufficiently recent versions of glibc and the Linux kernel". I am
running the latest Ubuntu which includes 2.6.28 so I would assume that
this is sufficient. My C is rusty so I haven't been able to test it.
-Joe
mats cronqvist wrote:
> Joe Williams <j...@joetify.com> writes:
>
>
>> I am seeing issues with this as well. I have some C++ code that uses
>> clock_gettime and it compiles and seems to work properly. But when I
>> configure Erlang it complains of it being unstable.
>>
>
> IIRC, it's not the existence of clock_gettime that is the problem,
> but which clk_ids it supports. Perhaps CLOCK_PROCESS_CPUTIME_ID.
>
> mats
mats cronqvist
> According to the man pages CLOCK_REALTIME, CLOCK_MONOTONIC,
> CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID are supported on
> "sufficiently recent versions of glibc and the Linux kernel". I am
> running the latest Ubuntu which includes 2.6.28 so I would assume that
> this is sufficient.
like I said earlier, the latest stable Debian does not install the
686-enabled libc automatically. Quite probably true about Ubuntu too.
Anyways, here's the test(found by greping in erts/configure).
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <stdio.h>
#include <time.h>
int main() {
long long start, stop;
int i;
struct timespec tp;
if (clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &tp) < 0)
exit(1);
start = ((long long)tp.tv_sec * 1000000000LL) + (long
long)tp.tv_ns$
for (i = 0; i < 100; i++)
clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &tp);
stop = ((long long)tp.tv_sec * 1000000000LL) + (long
long)tp.tv_nse$
if (start == 0)
exit(4);
if (start == stop)
exit(5);
exit(0); return 0;
Roger Critchlow
My config.log for otp_src_R13B says:
configure:19638: checking if clock_gettime can be used to get process CPU time
configure:19682: gcc -o conftest -g -O2 -I/usr/local/src/otp_src_R13B/erts/x86_64-unknown-linux-gnu -D_GNU_SOURCE conftest.c -lrt >&5
configure:19686: $? = 0
configure:19692: ./conftest
configure:19696: $? = 0
configure:19715: result: not stable, disabled
The compile of the test (line 19682) succeeded (line 19686), the test (line 19692) succeeded (line 19696), but the result of the test is ignored because the ac_local.m4 code mentioned at the start of the thread. That code ignores the result of the test, which is recorded in $erl_clock_gettime, when running linux.
case $host_os in
linux*)
AC_MSG_RESULT([not stable, disabled])
LIBRT=$xrtlib
;;
*)
true)
AC_DEFINE(HAVE_CLOCK_GETTIME,[],
[define if clock_gettime() works for getting process time])
AC_MSG_RESULT(using clock_gettime)
LIBRT=-lrt
;;
*)
AC_MSG_RESULT(not working)
LIBRT=$xrtlib
;;
esac
;;
esac
-- rec --
mats cronqvist
> Maybe I'm confused, but I think the problem is that configure ignores
> the test result under linux.
no, I think you're right. It does seem like they've disabled
CLOCK_PROCESS_CPUTIME_ID on linux.
Adam Kocoloski
> Roger Critchlow <r...@elf.org> writes:
>
>> Maybe I'm confused, but I think the problem is that configure ignores
>> the test result under linux.
>
> no, I think you're right. It does seem like they've disabled
> CLOCK_PROCESS_CPUTIME_ID on linux.
Whew, glad we're on the same page with that one. I don't do much
autotools work, but I was pretty sure the result of the test was
ignored.
Adam
mats cronqvist
> On May 14, 2009, at 7:03 AM, mats cronqvist wrote:
>
>> Roger Critchlow <r...@elf.org> writes:
>>
>>> Maybe I'm confused, but I think the problem is that configure ignores
>>> the test result under linux.
>>
>> no, I think you're right. It does seem like they've disabled
>> CLOCK_PROCESS_CPUTIME_ID on linux.
>
> Whew, glad we're on the same page with that one. I don't do much
> autotools work, but I was pretty sure the result of the test was
> ignored.
I just took for granted that it was the same problem I've dealt with
several times before. That was stupid.
mats