Re: [RFC PATCH] Turn off the tick even when not idle

[Josh Triplett <josh@joshtriplett.org>]

On Tue, Sep 01, 2009 at 03:56:56PM -0400, Christoph Lameter wrote:
> On Tue, 1 Sep 2009, Josh Triplett wrote:
> 
> > Please, give this patch a try and let me know what you think.
> 
> Looks quite good. The PNG shows more deterministic run time behavior.

Thanks; exactly what I hoped to demonstrate.  Actually making the timer
interrupt go away will require finding a more appropriate place to run
all the code that otherwise polls periodically, but this patch lets us
cheat and see the result before that happens. :)

> > I'd like to work towards a patch which really can kill off the timer
> > tick, making the kernel entirely event-driven and removing the polling
> > that occurs in the timer tick.  I've reviewed everything the timer tick
> > does, and every last bit of it could occur using an event-driven
> > approach.
> 
> Good idea. Thought so for a long time. Thanks for working on it. Many of
> the events can be deferred if nothing is happening in the system.
> vm statistics, data expiration from caches etc. Not sure what to do about
> the per cpu threads generated by various kernel subsystems though.

I ran the benchmark at realtime priority, and affinitized to a single
CPU.  I used ftrace to confirm that after the initial program setup
(shared library loads, memory allocation, etc), no code runs in the
kernel during the number-crunching; this makes sense, since I ran at
higher priority than all the random affinitized kernel threads, and I
pushed everything else (tasks and interrupts) onto another CPU.

Long-term I'd like to solve the problem of those kernel threads, but
realtime priority can mitigate those.  The new interrupt threading bits
may help with other interrupts and avoid the need to set interrupt
affinity.  The timer interrupt, though, represents the one and only
thing I can't mitigate, hence why I'd like to make it go away.

- Josh Triplett