Messages in this thread | | | Date | Tue, 1 Sep 2009 11:08:26 -0700 | From | Josh Triplett <> | Subject | Re: [RFC PATCH] Turn off the tick even when not idle |
| |
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
| |