Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755148AbZIASIE (ORCPT ); Tue, 1 Sep 2009 14:08:04 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755102AbZIASID (ORCPT ); Tue, 1 Sep 2009 14:08:03 -0400 Received: from relay1-v.mail.gandi.net ([217.70.178.75]:60267 "EHLO relay1-v.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754996AbZIASIB (ORCPT ); Tue, 1 Sep 2009 14:08:01 -0400 X-Greylist: delayed 8659 seconds by postgrey-1.27 at vger.kernel.org; Tue, 01 Sep 2009 14:08:01 EDT Date: Tue, 1 Sep 2009 11:08:26 -0700 From: Josh Triplett To: Christoph Lameter Cc: linux-kernel@vger.kernel.org, Anton Blanchard , Tim Pepper , Paul McKenney , John Stultz , Jamey Sharp Subject: Re: [RFC PATCH] Turn off the tick even when not idle Message-ID: <20090901180825.GA3621@josh-work.beaverton.ibm.com> References: <20090901154327.GA10024@feather> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2129 Lines: 42 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/