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. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
