[lkml]   [2006]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subjectsched_clock() uses are broken

    Someone just asked a question about sched_clock() on the ARM list, asking
    whether there was any way to find the range of values returned by this

    My initial thought was "why would you want that", but on considering the
    problem a bit further, I could see why the question arises. In looking
    deeper, I discovered a rather sad state of affairs with sched_clock().

    The kernel assumes that the following will work:

    unsigned long long t0, t1, time_passed_ns;

    t0 = sched_clock();
    /* do something */
    t1 = sched_clock();

    time_passed_ns = t1 - t0;

    This is all very well if sched_clock() returns values filling the
    entire range of an unsigned long long - two complement maths will
    naturally return the time difference in the case where t1 < t0.

    However, this is not the case. On x86 with TSC, it returns a 54 bit
    number. This means that when t1 < t0, time_passed_ns becomes a very
    large number which no longer represents the amount of time.

    All uses in kernel/sched.c seem to be aflicted by this problem.

    There are several solutions to this - the most obvious being that we
    need a function which returns the nanosecond difference between two
    sched_clock() return values, and this function needs to know how to
    handle the case where sched_clock() has wrapped.


    t0 = sched_clock();
    /* do something */
    t1 = sched_clock();

    time_passed = sched_clock_diff(t1, t0);


    Russell King
    Linux kernel 2.6 ARM Linux -
    maintainer of: 2.6 Serial core
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-05-02 15:32    [W:0.019 / U:20.648 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site