> 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
> 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
Thanks.
-Joe
--
Name: Joseph A. Williams
Email: j...@joetify.com
Blog: http://www.joeandmotorboat.com/
-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
> 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;
> 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.
> 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
> 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