sched_clock() uses are broken

[Russell King <rmk+lkml@arm.linux.org.uk>]

Hi,

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
function.

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.

IOW:

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

	time_passed = sched_clock_diff(t1, t0);

Comments?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core