linux-kernel - Re: [linux-pm] Higer latency with dynamic tick (need for an io-ondemand govenor?)

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: <alpine.LFD.1.10.0804190839140.3261@apollo.tec.linutronix.de>
Date:	Sat, 19 Apr 2008 09:13:40 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	David Brownell <david-b@...bell.net>
cc:	linux-pm@...ts.linux-foundation.org,
	"Woodruff, Richard" <r-woodruff2@...com>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org
Subject: Re: [linux-pm] Higer latency with dynamic tick (need for an io-ondemand
 govenor?)

On Fri, 18 Apr 2008, David Brownell wrote:
> On Friday 18 April 2008, Woodruff, Richard wrote:
> > When capturing some traces with dynamic tick we were noticing the
> > interrupt latency seems to go up a good amount. If you look at the trace
> > the gpio IRQ is now offset a good amount.  Good news I guess is its
> > pretty predictable.
> 
> That is, about 24 usec on this CPU ... an ARM v7, which I'm guessing
> is an OMAP34xx running fairly fast (order of 4x faster than most ARMs).
> 
> Similar issues were noted, also using ETM trace, on an ARM920 core [1]
> from Atmel.  There, the overhead of NO_HZ was observed to be more like
> 150 usec of per-IRQ overhead, which is enough to make NO_HZ non-viable
> in some configurations.
> 
> 
> > I was wondering what thoughts of optimizing this might be.
> 
> Cutting down the math implied by jiffies updates might help.
> The 64 bit math for ktime structs isn't cheap; purely by eyeball,
> that was almost 1/3 the cost of that 24 usec (mostly __do_div64).

Hmm, I have no real good idea to avoid the div64 in the case of a long
idle sleep. Any brilliant patches are welcome :)

Thanks,
	tglx