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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090901180825.GA3621@josh-work.beaverton.ibm.com>
Date:	Tue, 1 Sep 2009 11:08:26 -0700
From:	Josh Triplett <josh@...htriplett.org>
To:	Christoph Lameter <cl@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org, Anton Blanchard <anton@...ba.org>,
	Tim Pepper <lnxninja@...ux.vnet.ibm.com>,
	Paul McKenney <paulmck@...ux.vnet.ibm.com>,
	John Stultz <johnstul@...ibm.com>,
	Jamey Sharp <jamey@...ilop.net>
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/