[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.076 / U:2.772 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site