Re: [PATCHv2 4/6] sched_clock: Add support for >32 bit sched_clock

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

On Mon, Jun 10, 2013 at 08:46:36PM +0530, anish singh wrote:
> Probably a trivial question.I was wondering why this particular requirement
> exists in the first place.I looked into this commit 112f38a4a3 but couldn't
> gather the reason.

You're looking at a commit introducing an implementation.  The requirement
isn't driven by the implementation.  It's driven by the code and the maths
in the core scheduler, and its been a requirement for years.

sched_clock() needs to be monotonic, and needs to wrap at 64-bit, because
calculations are done by comparing the difference of two 64-bit values
returned from this function.

Let's take a trivial example - if you have a 16 bit counter, and you have
a value of 0xc000 ns, and next time you read it, it has value 0x0001 ns,
then what value do you end up with when you calculate the time passed
using 64-bit maths.

That's 0x0000000000000001 - 0x000000000000c000.  The answer is a very big
number which is not the correct 16385.  This means that things like process
timeslice counting and scheduler fairness is compromised - I'd expect even
more so if you're running RT and this is being used to provide guarantees.