lkml.org 
[lkml]   [2005]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Help with the high res timers
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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>

--
George Anzinger george@mvista.com
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-05-05 00:51    [W:0.054 / U:0.472 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site