linux-kernel - 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: <3B6D69C3A9EBCA4BA5DA60D91302742904131BED@dlee13.ent.ti.com>
Date:	Fri, 18 Apr 2008 10:43:32 -0500
From:	"Woodruff, Richard" <r-woodruff2@...com>
To:	"Thomas Gleixner" <tglx@...utronix.de>,
	"Ingo Molnar" <mingo@...e.hu>
Cc:	<linux-kernel@...r.kernel.org>,
	<linux-pm@...ts.linux-foundation.org>
Subject: Higer latency with dynamic tick (need for an io-ondemand govenor?)

Hi,

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.

* If we couple this with progressively higher latency C-States we see
that IO speed can fall by a good amount, especially for PIO mixes.  Now
if QOS is maintained you may or may-not care.

I was wondering what thoughts of optimizing this might be.

One thought was if an io-ondemand of some sort was used.  It could track
interrupt statistics and be feed back into cpu-idle.  When there is a
high interrupt load period it could shrink the acceptable latency and
thus help choose a good a C-State which favors throughput.  Some moving
average window could be used to track it.

Perhaps a new interrupt attribute could be attached at irq request time
to allow the tracking of bandwidth important devices.

The attached is captured on a .22 kernel.  The same should be available
in a bit on a .24 kernel.

Regards,
Richard W.

Download attachment "idle_trace.PNG" of type "image/png" (58498 bytes)