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]