[lkml]   [2005]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC][PATCH] new timeofday-based soft-timer subsystem
    Nishanth Aravamudan wrote:
    > * john stultz <> [2005-0429 15:45:47 -0700]:
    >> This patch implements the architecture independent portion of
    >>the time of day subsystem. For a brief description on the rework, see
    >>here: (Many thanks to the LWN team for
    >>that clear writeup!)
    > I have been working closely with John to re-work the soft-timer subsytem
    > to use the new timeofday() subsystem. The following patch attempts to
    > being this process. I would greatly appreciate any comments.

    Also working closely with John and Nish, I have been taking advantage of
    the new human-time soft-timer subsystem and the NO_IDLE_HZ code to
    dynamically schedule interrupts as needed. The idea is to have
    interrupt source drivers (PIT, Local APIC, HPET, ppc decrementers, etc)
    similar to the time sources in John's timeofday patches.

    Because the resolution of the soft-timer sybsystem is configurable via
    TIMER_INTERVAL_BITS, and the timeofday code is now free of the periodic
    system tick, we can move the soft-timers to a dynamically scheduled
    interrupt system. We can achieve both sub-millisecond timer resolution
    and NO_IDLE_HZ simply by adjusting TIMER_INTERVAL_BITS and scheduling
    the next timer interrupt appropriately whenever a soft-timer is added or

    In general at the end of set_timer_nsecs(), we see when the next timer
    is due to expire and pass that value (in absolute nanoseconds) to
    schedule_next_timer_interrupt(). Each interrupt source driver is then
    free to reprogram the hard-timer to the "best" interval. For something
    like the local APIC, that may be exactly when the next timer needs to go
    off. For the PIT, it may do nothing at all and just fire periodically.

    I have a prototype using the PIT, which just demonstrates that the
    system will still run this way. Obviously other timers will perform
    much better since the PIT is so slow to program.

    I feel that this is a clean approach to two soft-timer issues:
    resolution and NO_IDLE_HZ. It integrates well with the patches from
    John and Nish and is a direct approach to these issues, rather than an
    attempt to add support on top of a jiffies based soft-timer subsystem.

    I'd appreciate any feedback people have to offer. Particularly those
    that have been working on alternative approaches to things like high
    resolution timers and NO_IDLE_HZ.


    Darren Hart
    IBM Linux Technology Center
    Linux Kernel Team
    Phone: 503 578 3185
    T/L: 775 3185
    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-05-02 20:44    [W:0.033 / U:29.892 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site