[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.178 / U:1.540 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site