Re: Is there a problem in timeval_to_jiffies?

[Tim Bird <tim.bird@am.sony.com>]

Henry Margies wrote:
> Right? But for arm, with a jiffie size of 10000000, it is much
> more easier. And that is why I don't understand why an one second
> interval is converted to 101 jiffies (on arm).
...
> I agree. But then, why adding one jiffie to every interval? If
> there is no latency, the timer should appear right at the
> beginning of a jiffie. For x86 you are right, because 10 jiffies
> are less then 10ms. But for arm, 1 jiffie is precisely 10ms. 

How does the computer "know" that the timer is at the beginning
of the jiffy?  By definition, Linux (without HRT support) has
no way of dealing with sub-jiffy resolution for timers.

Maybe a graphic (ascii-graphic) will help:

tick 1 ---------------------




tick 2 ---------------------
schedule point A ->


schedule point B ->
tick 3 ---------------------




tick 4 ---------------------




tick 5 ---------------------


Let's say, that at point A, you ask for a 20 millisecond timer.
(2 jiffies, on ARM).  You think you are asking for a timer to fire
on tick 4 (20 milliseconds after tick 2), but Linux can't
distinguish point A from point B.  In order to avoid
the situation where someone scheduled a 20 millisecond timer
at point B, and had it fire on tick 4 (only 10 milliseconds
later), Linux adds one jiffy to the expiration time.
Both timers (set at point A or point B) would fire
on tick 5.  For the A timer, this makes it 30 milliseconds
(or, jiffies plus one) later, which looks pretty bad.
For the B timer, the interval would be close to 20
milliseconds, which looks pretty good.

If you are rescheduling one-shot timers immediately
after they fire, you should 'undershoot' on the time
interval, to hit the tick boundary you want, based
on the jiffy resolution of your platform.

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================