[lkml]   [2002]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Son of crunch time: the list v1.2.
    mbs wrote:
    > On Tuesday 22 October 2002 02:45, george anzinger wrote:
    > > > > > 9) High resolution timers (George Anzinger, etc.)
    > > > > >
    > > > >
    > > > > no comment, I've heard arguments that high-res timers would be useful,
    > > > > but haven't read the patch myself so won't comment...
    > > >
    > > > I vaguely remember Linus had some objections that it plays with the clock
    > > > tick and potentially penalizes everybody... Hmmm...
    > > >
    > > > A quick google comes up with this:
    > > >
    > > >
    > >
    > > Hm, I had not seen this. He is right, but the patch
    > > provides an out :) The standard says a timer can overrun.
    > > If a timer is repeating so fast as to bogdown the system,
    > > the code lumps enough of them to unload the system into the
    > > overrun count and doesn't take the interrupts.
    > > -g
    > (I haven't done my homework and looked in your patch)
    > you did notice the bit in posix about repeating timers and how you dont
    > reinsert a repeating timer until the signal handler has completed, right?

    What the standard says is that only one signal is to be
    queued for a given timer. Subsequent expires of the same
    timer then just bump the overrun count. This is what the
    patch does, but still this could overload the timer list and
    interrupt code, so in addition to the standard required
    overrun stuff, the code checks the next expire time and
    fudges a time at least X microseconds from now, where the
    time is a multiple (Y) of the repeat time + the current
    expire time. Y is then added to the overrun count to
    account for the missing expires.
    > that one bit me and we actually had to reimplement portions of our signals
    > mechanism to accomodate it.

    Yes, the signal code needs to check for that pending timer.
    And NOW (i.e. 2.5) it can be in either the shared list or
    the local list or both :(. This is in the patch.
    > that behavior ensures that a POSIX timer can't entirely dominate the system
    > (although it certainly can put a hurt on as can any number of other ill
    > advised programming blunders)

    I would be open to requiring a capability to run the repeat
    time below a fixed value if this would make folks happier.
    It would send the right message to the user, too, i.e. small
    repeat counts can be hazardous to your system.
    > it however doesn't do anything for kernel things using the timer
    > infrastructure....

    The interesting thing is that we don't currently have an in
    kernel call such as delay, etc. You just use add_timer().
    AND none of the possible interfaces I have seen or
    considered even hint at needing repeating timers.

    George Anzinger
    Preemption patch:
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:30    [W:0.032 / U:3.632 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site