  `Hi Linus,Thanks for your clarification, it does make sense. I did onlythe jiffies overflowing case, and missed the case where itdoes not overflow.Thanks,- KK-----------------------------------------------------------------------------Ok.Let's give an example. HZ is 100, and we started just before jiffieswrapped, and we want to check that we're within one second.So "start" equals 0xfffffff0, and "jiffies" equals 0xfffffff5.The first if-statement will say           if (0xfffffff5 <= 0xfffffff0+100)which is the same as           if (0xfffffff5 <= 0x54)which is           if (0)in short, the first statement will say that jiffies is _not_ within 100ticks of "start", which is obviously wrong. Jiffies _is_ within 100 ticks,it is in fact just 5 ticks after "start".The second statement will say           if (0xfffffff5 - 0xfffffff0 <= 100)which is           if (5 <= 100)which is           if (1)which is _correct_. We _are_ within 100 ticks.See?Ok, that was wrap-around one way: the "+HZ" wrapped. Let's see the othercase, which is that "jiffies" has wrapped: start is still 0xfffffff0, butjiffies has wrapped around and is 0x00000001.The first if-statement will say           if (0x00000001 <= 0xfffffff0+100)which is           if (0x00000001 <= 0x54)which is           if (1)which is correct. The second one will say           if (0x00000001 - 0xfffffff0 <= 100)which is           if (11 <= 100)which is           if (1)which is correct.In short, the _correct_ one ALWAYS gets the right answer. Even when thesubtraction overflows.While the first (and incorrect one) gets the wrong answer when theaddition overflows.Do you see the difference now?                     Linus-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.kernel.orgMore majordomo info at  http://vger.kernel.org/majordomo-info.htmlPlease read the FAQ at  http://www.tux.org/lkml/`   