On Mon, Jun 10, 2013 at 9:08 PM, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: Least I can do is to say "Thanks". > 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. Yes, and this is the question.If it is 32 bit then also it can overflow but it will happen relatively fast.So I guess that is the reason why we use 64 bit and this will avoid recalculations for recalibration. > > 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 So you mean when counter overflows the scheduler doesn't handle it? > 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
