Re: Help with the high res timers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



john stultz wrote:
On Wed, 2005-05-04 at 10:46 -0700, George Anzinger wrote:

Well, as long as the HZ period is close to the timer-interval unit
length, this is true. However if the timer-interval unit is smaller,
multiple bucket entries would be expired. The performance considerations
here are being looked at and this may be an area where the concepts in
HRT might help (having a HRT specific sub-bucket).

This is where we get in trouble with HR timers. For a HR timer, we need to know how to get a timer to expire (i.e. appear in the call back) at a well defined and precise time (leaving aside latency issues). The above description allows timers to be put in buckets without (as near as I can tell) making transparent exactly when the bucket will be emptied, only saying that it will be after the latest timer in the bucket is due.


<snip>

Think of it this way. Decompose a HR timer into coarse and fine units (you choose, but here let say jiffies and nanoseconds). Now we want the normal timer system to handle the jiffies part of the time and to turn the timer over to the HR timer code to take care of the nanosecond remainder. If the jiffie part is late, depending on the nanosecond part, it could make the timer late (i.e for low values of the nanosecond part). For high values of the nanosecond part, we can compenstate...

This decomposition makes a lot of sense, by the way, for, at least, the following reasons:
1) it keeps the most of the HR issues out of the normal timer code,
2) it keeps high res and low res timer in the correct time order, i.e. a low res timer for jiffie X will expire prior to a high res timer for jiffie X + Y nanoseconds. 3) handling the high res timer list is made vastly easier as it will only need to have a rather small number of timers in it at any given time (i.e. those that are to expire prior to the next coarse timer tick).



Hmmm. Ok I think I see what your getting at. Let me know where I go
wrong:

1. Since HR soft-timers are a special case, their absolute nanosecond
expire values (exp_ns) are decomposed into a low-res portion and a high-
res portion. In your case it is units of jiffies (exp_jf) and
arch_cycles (exp_ac) respectively.

2. Since jiffies units map directly to a periodic tick, one can set a
regular soft-timer to expire at exp_jf. Then when it is expired, it is
added to a separate HR-timers list to expire in exp_ac  arch_cycles
units.

3. With the new-timeofday rework and Nish's soft-timers code, the soft-
timers bucket entries map to actual nanosecond time values, rather then
ticks. This causes a problem with your two level (regular periodic and
hr-timer) timer-lists because since entries don't strictly map to
interrupts, you don't how to decompose the nanosecond expiration into
low-res and high-res portions.


Here is my possible solution: Still keeping Nish's soft-timer rework
where we use nanoseconds instead of ticks or jiffies, provide an
expected interrupt-period value, which gives you the maximum interval
length between ticks. Thus you schedule a regular-low-res timer for the
nanosecond value (exp_ns - expected_interrupt_period). When that timer
expires, you move the timer to the HR timer list and schedule an
interrupt for the remaining time.

Oh, I have been thinking along these same lines. I don't recall at the moment, but I depend on the timer retaining the absolute expire time as I set it. This is used both by the secondary timer, and by the rearm code. I need to look more closely at that. But this is picking things apart at a very low level and does not, I think, address timer ordering to the point where I feel completely safe. I.e. will such a scheme allow a LR time at time X to expire after a HR timer for time X+y.

Let me know how that sounds.

thanks
-john

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


--
George Anzinger   [email protected]
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux