pkg://hwtools_0.3-4.deb:219462/
usr/
doc/
hwtools/irqtune.html
info downloads
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN//3.0">
<HTML>
<HEAD>
<CENTER>
<TITLE>IRQTUNE -- A Linux IRQ Priority Optimizer</TITLE>
</CENTER>
</HEAD>
<BODY>
<P><P>
<CENTER>
<HR>
<H1>
<A NAME="__irqtune_0__"><EM>IRQTUNE</EM> -- A Linux IRQ Priority Optimizer</A>
</H1>
</CENTER>
<CENTER>
<EM>
Copyright 1996, 1997 by Craig Estey.
<BR>
<STRONG>
irqtune version 0.6
</STRONG>
<BR>
Last updated: Sun Oct 19 16:35:00 PDT 1997
<BR>
See the <A HREF="#__irqtune_66__">Changes</A> section at the bottom of this document.
<BR>
<A HREF="#__irqtune_72__">Table of Contents</A>
</EM>
</CENTER>
<P>
<EM>irqtune</EM> changes the IRQ priority of devices to allow devices that require
high priority and fast service (e.g. serial ports, modems) to have it.
<P>
<STRONG>
With <EM>irqtune</EM>, a 3X speedup of serial/modem throughput is possible.
</STRONG>
<P>
<P><P>
<HR>
<H1>
<A NAME="__irqtune_1__">Where do I get <EM>irqtune</EM>?</A>
</H1>
<EM>irqtune</EM> is free software under the terms and conditions of the GNU Public
License. See the file COPYING, included in the distribution, for details.
<P>
<UL>
<LI>
The author is Craig Estey, (<A HREF="MAILTO:cae@best.com">cae@best.com</A>).
<P>
<LI>
This FAQ is available online via
<A HREF="http://www.best.com/~cae/irqtune">http://www.best.com/~cae/irqtune</A>. This is the most authoritative reference
and will always contain the most up-to-date information.
<P>
<LI>
The distribution is a gzipped tar archive that contains all programs, sources,
and this FAQ (in both HTML and text versions). It is available from:
<P>
<UL>
<LI>
<A HREF="http://www.best.com/~cae/irqtune/irqtune.tgz">http://www.best.com/~cae/irqtune/irqtune.tgz</A>
<BR>
<LI>
<A HREF="ftp://shell5.ba.best.com/pub/cae/irqtune.tgz">ftp://shell5.ba.best.com/pub/cae/irqtune.tgz</A>
<BR>
</UL>
</UL>
<P>
<P><P>
<HR>
<H1>
<A NAME="__irqtune_2__">How do I know if I need <EM>irqtune</EM>?</A>
</H1>
<STRONG>You are running Linux on an x86 PC, other architectures to be implemented</STRONG>
<STRONG>later--Sorry.</STRONG>
<P>
<STRONG>
You probably need <EM>irqtune</EM>, if you are experiencing any of the following:
</STRONG>
<P>
<UL>
<LI>
SLIP/PPP transfers seem slow. For example, using a 28.8 (or better) modem,
the effective throughput is approximately 700 bytes/second instead of the
expected 2500 bytes/second.
<P>
<LI>
A running serial or SLIP/PPP connection is slow, drops data, hangs, or
times out.
<P>
<LI>
Netscape hangs mysteriously or stalls when trying to access a web page.
<P>
<LI>
Equivalent serial/PPP programs under Windoze run much faster than under Linux.
<P>
<LI>
Disk accesses seem to interfere with SLIP/PPP.
<P>
<LI>
Interrupt handlers for specialized, time critical devices don't get control
when they need to.
<P>
</UL>
<P><P>
<HR>
<H1>
<A NAME="__irqtune_3__">What is actually happening to cause these problems?</A>
</H1>
<P>
When the PC boots Linux, the timer is
given, by default, the highest IRQ priority in the system (it's IRQ 0 and thus,
priority 0). On a standard configuration, the serial ports are priority
11 and 12!!! This means that 10 other devices have higher priority.
<P>
<P><P>
<H3>
<A NAME="__irqtune_4__">Q: So what does IRQ priority do?</A>
</H3>
<P>
When multiple devices are in contention to interrupt the CPU, their priority
decides which interrupts will occur in what order.
<P>
<P><P>
<H3>
<A NAME="__irqtune_5__">Q: When does this contention occur?</A>
</H3>
<P>
After an arbitrary period of having interrupts disabled (e.g after a <EM>cli</EM>),
at the point where they're reenabled (<EM>sti</EM>). This can happen in several
places:
<P>
<UL>
<LI>
In an ISR that runs with interrupts locked, it happens in the <EM>epilog</EM>, just
before attempting to execute the <EM>bottom-half</EM>.
<P>
<LI>
The <EM>bottom-half</EM> itself may do a lock and unlock.
<P>
<LI>
When a task that enters the kernel to do a system call, the system call
handler may lock and unlock interrupts briefly.
<P>
<LI>
Almost anywhere in the kernel are brief periods where it does a <EM>cli</EM> to
lock interrupts and then an <EM>sti</EM> to unlock them again.
<P>
<LI>
Under Linux, from the moment the first instruction of the ISR <EM>prolog</EM> is
executed until an <EM>sti</EM> is done (This occurs even in <EM>slow</EM> interrupts
where the <EM>prolog</EM> does an <EM>sti</EM> after just a few instructions).
<P>
</UL>
<P><P>
<H3>
<A NAME="__irqtune_6__">Q: If there are multiple interrupts now pending, which one gets the service, the serial or some other?</A>
</H3>
<P>
In the default configuration, the serial ISR will usually lose as it's
priority 11.
<P>
<P><P>
<HR>
<H1>
<A NAME="__irqtune_7__">How does irqtune help this?</A>
</H1>
<P>
<EM>irqtune</EM> gives priority 0 to whatever device we specify. If we
specify
a serial device, <EM>irqtune</EM> guarantees that the serial ISR gets control
whenever a contention occurs.
<P>
<P><P>
<HR>
<H1>
<A NAME="__irqtune_8__">Why does the serial interrupt service require the highest priority?</A>
</H1>
<P>
<P><P>
<H3>
<A NAME="__irqtune_9__">Q: Why does the serial device merit such special treatment?</A>
</H3>
<P>
Serial devices are somewhat unique. Even though they have one of
the slowest data rates (relative to a disk), they are the largest consumer
of interrupts and are extremely sensitive to <EM>interrupt latency</EM> (the time
from when a device yanks the IRQ line until its ISR is executed).
<P>
<P><P>
<H3>
<A NAME="__irqtune_10__">Q: Could you give a concrete example of this?</A>
</H3>
<P>
<UL>
<LI>
For a modem running at 33.6, we can have a peak maximum (with
compression) of 6700 bytes/second. The serial driver programs the silo to
interrupt after 8 bytes, leaving a latency window of 8 bytes. This means
that when the serial port yanks its IRQ line, it can still absorb 8 more
characters before its buffer will overflow and data will be dropped
<P>
<LI>
In terms of time, this means that the maximum that the serial ISR may be
delayed is
(8 / 6700) seconds or 1194 microseconds. It also means that the serial ISR
will require 838 interrupts/second.
<P>
<LI>
Currently there are 52 devices that install their ISR with the SA_INTERRUPT
option.
This means that they wish to run with interrupts disabled.
I have not looked at all the devices, but just
assume for the moment that all will run with interrupts locked for an
arbitrary period.
<P>
<LI>
Assume we've got 4 of them pending (remember,
at <EM>higher</EM> priority). Assume that they will lock interrupts individually
for 320, 300, 190, and 500 microseconds, respectively. Assume that the
serial ISR also wants an interrupt.
<P>
<LI>
This means that the serial ISR will have to wait for (320 + 300 + 190 + 500)
or 1310us
for these other higher priority ISR's to run to completion. This is greater
than the maximum of 1194 us.
<P>
<LI>
With internal
modems, we probably just see start/stop behavior causing a slowdown.
With an external modem, <STRONG>data will be dropped</STRONG>. This will cause PPP to see
a CRC error and request transmission. Remember, the <EM>entire</EM> packet must be
retransmitted, which means we just wasted 296-1500 bytes (depending on the
selected MRU).
With an MRU of 1500 bytes, we just
wasted 23.4% of the bandwidth in a given second--all for the loss of a single
byte!
<P>
<LI>
Worse yet, consider a 115 Kbps ISDN card that is
masquerading as a serial device <EM>(Yes, I know it should be a DMA device)</EM>.
In this case, the maximum delay the serial ISR can wait is 695 us. And that's
just one ISDN channel. Try adding the other and, well, <EM>golly :-)</EM>.
<P>
</UL>
<P>
<P><P>
<H3>
<A NAME="__irqtune_11__">Q: In this example, how would boosting serial IRQ priority help?</A>
</H3>
<UL>
<LI>
If the serial IRQ had priority 0, it would get in <EM>before</EM> the others. It
could also <STRONG>re-interrupt</STRONG> after any individual lockout window. Thus, the
maximum
it would be forced to wait would be largest individual time, not the
<STRONG>summation</STRONG> of all of these times. In this example, this means 500 us.
which is now within the 1194 us. maximum for the serial ISR.
<P>
<LI>
It has been my experience that the serial device <STRONG>must always</STRONG> win these
battles for contention. When serial devices don't get what they <EM>need</EM>,
when they need it, they slow horribly or drop data outright.
<P>
</UL>
<P>
<P><P>
<HR>
<H1>
<A NAME="__irqtune_12__">Isn't that example very <EM>unlikely</EM> under Linux?</A>
</H1>
<P>
<EM>Unlikely</EM> doesn't mean never. There are places were the contention period
<STRONG>must</STRONG> occur, no matter how we program the CPU.
<P>
Variations in CPU speed,
RAM size, RAM speed, cache size, disk speed, disk rotational position,
number and type of other devices, system workload, etc, etc etc, all
contribute to variations of order and timing of internal OS events.
<P>
<EM>Unlikely</EM> on one system may mean 1/1000th % chance. On another system, it
may mean <EM>happens 50 times/second</EM>. Beyond a certain point, it all comes
down to <EM>measurement</EM>.
<P>
Tight, accurate, repeatable measurement is the key
to system tuning. If we can't measure it, we can't tune it. Once we
<EM>can</EM> measure
these things, we can then <EM>try</EM> various combinations until we achieve
our desired results. It can often be pointless to guess at performance.
<P>
In fact, the interrupt disable windows themselves are used to prevent data
corruption caused by various parts of the kernel that try to update a data
structure simultaneously and get corrupted. Many of these windows are put
there in the <EM>unlikely</EM> case that such corruption would occur. In this
context, <EM>unlikely</EM> is <STRONG>never</STRONG> considered a reason to forego interrupt
locking. Eliminating a necessary interrupt lock window could result in
kernel panics, RAM corruption, disk data corruption, etc.
<P>
<P><P>
<HR>
<H1>
<A NAME="__irqtune_13__">Doesn't this hurt the performance of other devices?</A>
</H1>
<P>
<STRONG>Not really</STRONG>.
<P>
In actual practice, most devices don't even notice the difference.
Most other
devices (e.g. disks, tape, ethernet) are <EM>DMA</EM> devices. The <EM>DMA</EM> does
most of the work, thus greatly reducing their need for interrupts. If the
device allows a request queue, it may function autonomously on several
requests, producing only one interrupt for the entire batch.
<P>
Furthermore, serial interrupt services are, themselves, <EM>very</EM> fast. They
slam their data as quickly as possible and get out ASAP. No fancy
calculations, just the minimum, mindless data transfer. Almost everything
else is handled later, in the <EM>bottom-half</EM> with interrupts enabled. In
fact, a serial ISR may have to re-interrupt it's own <EM>bottom-half</EM> several
times.
<P>
Those devices that
<EM>do</EM> experience some slight slowdown are more likely to have long interrupt
disable windows themselves. Having several smaller <EM>cli/sti</EM> windows is
much better than one large <EM>cli/sti</EM> window--It's just harder to program.
<P>
<P><P>
<H3>
<A NAME="__irqtune_14__">Q: But suppose I want a balanced priority system?</A>
</H3>
<P>
Well, actually a <EM>prioritized</EM> system behaves like a <EM>balanced</EM>
system--most of the time. This occurs when all devices have short interrupt
lockout windows and short ISR execution times. The priority mechanism is
like a safety valve--it only really matters when some device or combination
of devices has held interrupts locked for an extended period of time.
<P>
<P><P>
<H3>
<A NAME="__irqtune_15__">Q: But doesn't that seem <EM>unfair</EM> to other devices?</A>
</H3>
<P>
When a disk ISR gets delayed,
that's all that happens, a slight delay--disks and tapes are <STRONG>not</STRONG> real-time
devices. When a serial ISR gets delayed, data is destroyed--serial devices
<STRONG>are</STRONG> real-time devices that dictate the cadence of the entire system.
<P>
<STRONG>
It may sound cruel, but you just can't be <EM>fair</EM>.
</STRONG>
<P>
And speaking of sound, if the sound card gets delayed,
we hear an annoying pop right in the middle of our favorite piece of music.
<P>
These are real-time devices that can <STRONG>not</STRONG> tolerate excessive delays. If we
must defer some less time critical devices to meet the minimum real-time
criteria of devices, then that's a bargain.
<P>
<P><P>
<H3>
<A NAME="__irqtune_16__">Q: But suppose I really want both fast serial and fast disk?</A>
</H3>
<P>
Ultimately, it's a bit of a compromise. Which is better:
<BR>
<UL>
<LI>
Reliable serial and <EM>slightly</EM> slower disk.
<BR>
<LI>
<EM>Slightly</EM> faster disk and <EM>unreliable</EM> serial/modem support.
<BR>
</UL>
<EM>
When paying an ISP for Internet access in $$$/hour, it's an easy decision :-).
</EM>
<P>
<P><P>
<HR>
<H1>
<A NAME="__irqtune_17__">Isn't this IRQ priority thing a bit of a new idea?</A>
</H1>
<P>
No. It's actually an old idea. I've been doing device drivers since 1977
and Unix kernel work since 1981. I've personally written 8 serial drivers
have used this many times commercially. Giving the serial device the
highest priority is actually standard practice in many systems.
<EM>With a 4Mhz CPU, these problems used to occur at 1200 baud :-)</EM>
<P>
<P><P>
<HR>
<H1>
<A NAME="__irqtune_18__">How do I install <EM>irqtune</EM>?</A>
</H1>
<P>
<P><P>
<H3>
<A NAME="__irqtune_19__">Q: Where should I place <EM>irqtune</EM> files?</A>
</H3>
<UL>
<LI>
Decide what directory you would like to <STRONG>contain</STRONG> <EM>irqtune</EM>'s
home directory.
Some good choices are:
<STRONG>/usr/local</STRONG>,
<STRONG>/usr/lib</STRONG>,
<STRONG>/usr/lib/hwtools</STRONG>,
<STRONG>/home</STRONG>.
<BR>
<LI>
Exactly where depends upon your local conventions.
<BR>
<LI>
In this example, we'll use <STRONG>/usr/local</STRONG>.
<BR>
</UL>
<P>
<P><P>
<H3>
<A NAME="__irqtune_20__">Q: How do I unpack the archive?</A>
</H3>
<UL>
<LI>
Go to the containing directory.
<BR>
<CODE>
cd /usr/local
<BR>
</CODE>
<LI>
Unpack the tar file:
<BR>
<CODE>
tar zxvf irqtune.tgz
<BR>
</CODE>
<LI>
This will create a directory, <STRONG>irqtune</STRONG> in <STRONG>/usr/local</STRONG>. This is
<STRONG>/usr/local/irqtune</STRONG>. We will call this <STRONG>IRQTUNE_HOME</STRONG>.
<BR>
</UL>
<P>
<EM>
Note: If tar's
</EM>
<STRONG>z</STRONG>
<EM>
option has problems:
</EM>
<BR>
<UL>
<LI>
An alternate unpack command:
<BR>
<CODE>
gzip -d < irqtune.tgz | tar xvf -
<BR>
</CODE>
</UL>
<P>
<P><P>
<H3>
<A NAME="__irqtune_21__">Q: How do I do a simple installation?</A>
</H3>
<UL>
<LI>
Go to the <STRONG>IRQTUNE_HOME</STRONG> directory:
<BR>
<CODE>
cd /usr/local/irqtune
<BR>
</CODE>
<LI>
To install <EM>irqtune</EM>, enter:
<BR>
<CODE>
make install
<BR>
</CODE>
<LI>
This will install the files:
<BR>
<CODE>
/sbin/irqtune
<BR>
/sbin/irqtune_mod.o
<BR>
/sbin/irqtune_npr.o
<BR>
</CODE>
</UL>
<P>
<P><P>
<H3>
<A NAME="__irqtune_22__">Q: Why are .o files being placed in the /sbin directory?</A>
</H3>
<P>
<EM>
As a note to purists, the installation directory is completely arbitrary.
<STRONG>/sbin</STRONG> is short, sweet, and easy to type.
</EM>
<P>
The standard convention would be to install <STRONG>irqtune</STRONG> as <STRONG>/sbin/irqtune</STRONG>
and the .o files as, say, <STRONG>/usr/lib/irqtune/*.o</STRONG>.
<EM>irqtune</EM> uses a slightly different convention. It wants all installed
files to be in the same directory.
This works fine because argv[0] will
point to the .o files. This also allows:
<BR>
<UL>
<LI>
Multiple versions of <EM>irqtune</EM> to be installed simultaneously (in different
directories).
<BR>
<LI>
Simplifies testing of new versions.
<BR>
<LI>
Provides better assurance that the built version is correct.
<BR>
<LI>
Using one directory produces less clutter.
<BR>
<LI>
One directory is more portable across all the myriad kernel revisions.
<BR>
<LI>
Future versions of <EM>irqtune</EM> may imbed the .o's directly into <STRONG>irqtune</STRONG>.
<BR>
</UL>
<P>
<P><P>
<H3>
<A NAME="__irqtune_23__">Q: What if I really don't want .o files in <STRONG>/sbin</STRONG>?</A>
</H3>
<P>
If placing .o files in <STRONG>/sbin</STRONG> is deemed to be an
anathema, we have two options:
<BR>
<UL>
<LI>
Simply use another directory in place of <STRONG>/sbin</STRONG>:
<BR>
<CODE>
make SBIN=/whatever install
<BR>
</CODE>
<LI>
Install with a stub (This will install /sbin/irqtune as a shell script and use
<STRONG>IRQTUNE_HOME</STRONG>/sbin/irqtune_*.o):
<BR>
<CODE>
make INSTALL=sh install
<BR>
</CODE>
</UL>
<P>
<P><P>
<H3>
<A NAME="__irqtune_24__">Q: Are there any special considerations for this alternate installation method?</A>
</H3>
<P>
Yes. If the shell/stub installation method is used:
<BR>
<UL>
<LI>
<STRONG>IRQTUNE_HOME</STRONG> must not be removed.
<BR>
<LI>
If using <EM>irqtune</EM> from an /etc/rc.d/rc.* file <STRONG>and</STRONG> <EM>irqtune</EM> will be
invoked <STRONG>before</STRONG> secondary mounts are done, <STRONG>IRQTUNE_HOME</STRONG> should be
placed on the root device.
<BR>
</UL>
<P>
<P><P>
<HR>
<H1>
<A NAME="__irqtune_25__">How do I use <EM>irqtune</EM>? Don't I have to rebuild my kernel?</A>
</H1>
No, we do <STRONG>not</STRONG> have to rebuild the kernel. <EM>irqtune</EM> uses <EM>insmod</EM>
and
<EM>rmmod</EM> to dynamically load and unload a kernel module. But it is correct
to sense that irqtune is a kernel patch.
<P>
<P><P>
<H3>
<A NAME="__irqtune_26__">Q: Ok, if it's a kernel patch, why not just issue a kernel patch like everybody else does (e.g. diff -u output)?</A>
</H3>
<P>
<EM>irqtune</EM> will work even if we don't have the kernel source loaded. It uses
<EM>insmod</EM> to load the patch, invoke it, and then unload it. The IRQ priority
changes will last so long as the kernel is booted.
<P>
<P><P>
<H3>
<A NAME="__irqtune_27__">Q: How do we invoke it?</A>
</H3>
<P>
<EM>irqtune</EM> takes two arguments optional arguments:
<BR>
<UL>
<LI>
irqtune <EM>master</EM> <EM>slave</EM>
<BR>
</UL>
The default is <EM>3 14</EM> which will work for many standard configurations.
See <A HREF="#__irqtune_31__">What about my non-standard hardware configuration?</A> for details.
<BR>
<UL>
<LI>
Here is the usage output from irqtune:
<BR>
<CODE>
usage: irqtune [options] [master] [slave]
<BR>
version: 0.6
<BR>
arguments:
<BR>
master -- high priority IRQ on PIC master (DEFAULT: 3)
<BR>
slave -- high priority IRQ on PIC slave (DEFAULT: 14)
<BR>
general options:
<BR>
-h -- display help
<BR>
-v -- display irqtune version
<BR>
-o -- reset to original values (0/8)
<BR>
priority table options:
<BR>
-q -- suppress priority table printing
<BR>
-s -- sort table by priority
<BR>
-x -- show inactive devices in table
<BR>
error control options:
<BR>
-e -- show full errors
<BR>
-f -- force loading even if probe detects errors
<BR>
-u -- force module unload
<BR>
-V -- insmod verbose mode
<BR>
-w -- treat warnings as errors
<BR>
documentation options:
<BR>
-F<file> -- use <file> instead of /proc/interrupts
<BR>
-i -- install program
<BR>
-L<directory> -- directory to search for insmod
<BR>
-n -- nogo mode (just show what would happen)
<BR>
</CODE>
</UL>
<P>
<P><P>
<H3>
<A NAME="__irqtune_28__">Q: Could we do this from my /etc/rc.d/rc.local file?</A>
</H3>
<P>
Yes. Just add a <STRONG>/sbin/irqtune</STRONG> line to this file and we're
in business.
We may also issue another <EM>irqtune</EM> command at any time.
<P>
<P><P>
<H3>
<A NAME="__irqtune_29__">Q: What if irqtune fails to load?</A>
</H3>
See the <A HREF="#__irqtune_42__">What about <EM>irqtune</EM> load failures or incompatibilities with kernel revisions?</A> section.
<P>
<P><P>
<H3>
<A NAME="__irqtune_30__">Q: After <EM>irqtune</EM> sets a priority, how can we query the results later?</A>
</H3>
<P>
<STRONG>
We can't.
</STRONG>
<P>
Due to a limitation of the PC interrupt hardware, it is <STRONG>not</STRONG> possible
to read back values set previously.
<P>
<EM>irqtune</EM> will attempt to place a message in the system log
(/usr/spool/syslog/syslog) when it changes the configuration. Examining this
log file, or simply invoking <EM>irqtune</EM> again,
may be the best ways to work around the hardware limitations.
<P>
<EM>
Note: Some users have tried to use the "-n" option, thinking it
will act as a "query" mode. This option is used, primarily, to generate
examples in this document and will not have the desired effect.
</EM>
<P>
<P><P>
<HR>
<H1>
<A NAME="__irqtune_31__">What about my non-standard hardware configuration?</A>
</H1>
<EM>irqtune</EM> defaults for a standard IRQ configuration. It assumes that the
highest priority device should be on IRQ 3. This is normally the first serial
port on standard configurations, which is what you want.
<P>
<P><P>
<H3>
<A NAME="__irqtune_32__">Q: How do I determine what my IRQ configuration is?</A>
</H3>
<P>
<EM>
NOTE: For brevity, we've combined the non-sorted and sorted output in
these examples.
</EM>
<BR>
<UL>
<LI>
Just type <STRONG>/sbin/irqtune -n -o</STRONG> and we'll get something like:
<BR>
<CODE>
SORTED BY IRQ: SORTED BY PRIORITY:
<BR>
I00/P00: 8578913 timer I00/P00: 8578913 timer
<BR>
I01/P01: 109547 keyboard I01/P01: 109547 keyboard
<BR>
I02/P02: 0 + cascade I02/P02: 0 + cascade
<BR>
I03/P10: 86470 + serial I11/P05: 197648 + sermux
<BR>
I04/P11: 197648 + serial I12/P06: 17968 + eth
<BR>
I11/P05: 197648 + sermux I13/P07: 1 math error
<BR>
I12/P06: 17968 + eth I14/P08: 93123 + Ux4F
<BR>
I13/P07: 1 math error I03/P10: 86470 + serial
<BR>
I14/P08: 93123 + Ux4F I04/P11: 197648 + serial
<BR>
</CODE>
</UL>
<P>
<EM>
NOTE:
<STRONG>/proc/interrupts</STRONG>, and therefore irqtune, only reports on active devices.
So to scope out
the serial IRQ's, ideally, you'd have X Windows up with your serial mouse and
be connected via PPP to the net.
</EM>
<P>
<P><P>
<H3>
<A NAME="__irqtune_33__">Q: OK, we've got the output from /sbin/irqtune -n -o, what do we do with it?</A>
</H3>
<P>
The leftmost number is the IRQ number. The next number is the priority.
The rightmost column is the <STRONG>internal</STRONG>
device name (not to be confused with /dev names). In the above case, the two
serial ports are on IRQ 3 and IRQ 4. Just use the lower number, in this
case 3:
<BR>
<UL>
<LI>
<STRONG>/sbin/irqtune</STRONG> <EM>3</EM>
<BR>
</UL>
This sets IRQ 3 to the highest priority.
<P>
<UL>
<LI>
After this command, the IRQ priorities are now:
<BR>
<CODE>
SORTED BY IRQ: SORTED BY PRIORITY:
<BR>
I00/P05: 8578913 timer I03/P00: 86470 + serial
<BR>
I01/P06: 109547 keyboard I04/P01: 197648 + serial
<BR>
I02/P07: 0 + cascade I00/P05: 8578913 timer
<BR>
I03/P00: 86470 + serial I01/P06: 109547 keyboard
<BR>
I04/P01: 197648 + serial I02/P07: 0 + cascade
<BR>
I11/P12: 197648 + sermux I14/P07: 93123 + Ux4F
<BR>
I12/P13: 17968 + eth I11/P12: 197648 + sermux
<BR>
I13/P14: 1 math error I12/P13: 17968 + eth
<BR>
I14/P07: 93123 + Ux4F I13/P14: 1 math error
<BR>
</CODE>
</UL>
<P>
<P><P>
<H3>
<A NAME="__irqtune_34__">Q: BTW, What's the cascade device I saw in the output of irqtune?</A>
</H3>
<P>
Glad you asked. There are actually two interrupt controllers, a <EM>master</EM>
and a <EM>slave</EM>. The <EM>slave</EM> is <EM>cascaded</EM> to the <EM>master</EM> via its IRQ 2.
The <EM>master</EM> controls IRQ's 0-7 and the <EM>slave</EM> controls IRQ's 8-15.
<P>
You actually may select two high IRQ priorities, one for the <EM>master</EM> and one
for the <EM>slave</EM>. <EM>irqtune</EM> defaults the <EM>slave</EM> to IRQ 14, which is
normally the disk controller.
<P>
In fact, <EM>cascade</EM> is sort of a "zero width" device as it does not
contribute to interrupt latency. Setting the <EM>cascade</EM> to top
priority on the <EM>master</EM> has an interesting effect which we'll see shortly.
<P>
<P><P>
<H3>
<A NAME="__irqtune_35__">Q: But we've also got an Ethernet controller on IRQ 12. What about that?</A>
</H3>
<P>
In this case, we might want to use:
<BR>
<UL>
<LI>
<STRONG>/sbin/irqtune</STRONG> <EM>3 12</EM>
<BR>
</UL>
because we want our ethernet card to have a higher priority than the disk
controller. Actually if we did have this configuration, setting 3 14
(the default) would make the ethernet card, the lowest priority device in the
system.
<P>
<UL>
<LI>
The resulting priority would be:
<BR>
<CODE>
SORTED BY IRQ: SORTED BY PRIORITY:
<BR>
I00/P05: 8578913 timer I03/P00: 86470 + serial
<BR>
I01/P06: 109547 keyboard I04/P01: 197648 + serial
<BR>
I02/P07: 0 + cascade I00/P05: 8578913 timer
<BR>
I03/P00: 86470 + serial I01/P06: 109547 keyboard
<BR>
I04/P01: 197648 + serial I02/P07: 0 + cascade
<BR>
I11/P14: 197648 + sermux I12/P07: 17968 + eth
<BR>
I12/P07: 17968 + eth I13/P08: 1 math error
<BR>
I13/P08: 1 math error I14/P09: 93123 + Ux4F
<BR>
I14/P09: 93123 + Ux4F I11/P14: 197648 + sermux
<BR>
</CODE>
</UL>
<P>
<P><P>
<H3>
<A NAME="__irqtune_36__">Q: What about the serial multiplexer card on IRQ 11?</A>
</H3>
<P>
This is a bit tricky because now we've got a serial device on
the <EM>slave</EM> controller. It would be much better to put all serial cards on
the <EM>master</EM> controller. Things would stay much simpler.
<P>
In this case we would want to use:
<BR>
<UL>
<LI>
<STRONG>/sbin/irqtune</STRONG> <EM>11</EM>
<BR>
<LI>
The resulting priorities would be more complex and would result in something
like:
<BR>
<CODE>
SORTED BY IRQ: SORTED BY PRIORITY:
<BR>
I00/P13: 8578913 timer I02/P00: 0 + cascade
<BR>
I01/P14: 109547 keyboard I11/P00: 197648 + sermux
<BR>
I02/P00: 0 + cascade I12/P01: 17968 + eth
<BR>
I03/P08: 86470 + serial I13/P02: 1 math error
<BR>
I04/P09: 197648 + serial I14/P03: 93123 + Ux4F
<BR>
I11/P00: 197648 + sermux I03/P08: 86470 + serial
<BR>
I12/P01: 17968 + eth I04/P09: 197648 + serial
<BR>
I13/P02: 1 math error I00/P13: 8578913 timer
<BR>
I14/P03: 93123 + Ux4F I01/P14: 109547 keyboard
<BR>
</CODE>
</UL>
<P>
<P><P>
<H3>
<A NAME="__irqtune_37__">Q: Wait a minute. didn't we just specify a <EM>slave</EM> IRQ number as the <EM>master</EM> to <EM>irqtune</EM>?</A>
</H3>
<P>
Yes, this is shorthand way of saying <EM>2 11</EM>. You can make a <EM>slave</EM>
device top priority, but we get no options for the <EM>master</EM> IRQ. It
will always be <EM>2</EM>, the <EM>cascade</EM> device. Remember, the <EM>cascade</EM>
device contributes no latency delay by itself.
<P>
<P><P>
<H3>
<A NAME="__irqtune_38__">Q: So why is this configuration so bad?</A>
</H3>
<P>
Well, we boosted the priority of the serial multiplexer at the expense of the
regular serial ports. The only way to allow all serial ports equally high
priority is to group them on consecutive IRQ's and set the high priority for
the lowest of those IRQ's.
<P>
<P><P>
<H3>
<A NAME="__irqtune_39__">Q: How can we fix this with software?</A>
</H3>
<P>
<STRONG>
We can't.
<P>
We're limited by the architecture of the PC and its interrupt controllers.
We must change the IRQ of a device by physical restrapping--we can't
do it by reprogramming the priority alone.
</STRONG>
<P>
We'll go back to the earlier example. We'll wave a magic wand and
<EM>Poof!</EM>--assume we just restrapped the serial multiplexer to IRQ 5:
<BR>
<UL>
<LI>
<STRONG>/sbin/irqtune</STRONG> <EM>3</EM>
<BR>
<LI>
The resulting priorities would be:
<BR>
<CODE>
SORTED BY IRQ: SORTED BY PRIORITY:
<BR>
I00/P05: 8578913 timer I03/P00: 86470 + serial
<BR>
I01/P06: 109547 keyboard I04/P01: 197648 + serial
<BR>
I02/P07: 0 + cascade I05/P02: 197648 + sermux
<BR>
I03/P00: 86470 + serial I00/P05: 8578913 timer
<BR>
I04/P01: 197648 + serial I01/P06: 109547 keyboard
<BR>
I05/P02: 197648 + sermux I02/P07: 0 + cascade
<BR>
I12/P13: 17968 + eth I14/P07: 93123 + Ux4F
<BR>
I13/P14: 1 math error I12/P13: 17968 + eth
<BR>
I14/P07: 93123 + Ux4F I13/P14: 1 math error
<BR>
</CODE>
</UL>
<P>
<P><P>
<H3>
<A NAME="__irqtune_40__">Q: Could we do more of this restrapping, say, with the ethernet controller?</A>
</H3>
<P>
Sure. Waving the wand again, we restrap the ethernet card to IRQ 6.
<BR>
<UL>
<LI>
<STRONG>/sbin/irqtune</STRONG> <EM>3</EM>
<BR>
<LI>
The resulting priorities would be:
<BR>
<CODE>
SORTED BY IRQ: SORTED BY PRIORITY:
<BR>
I00/P05: 8578913 timer I03/P00: 86470 + serial
<BR>
I01/P06: 109547 keyboard I04/P01: 197648 + serial
<BR>
I02/P07: 0 + cascade I05/P02: 197648 + sermux
<BR>
I03/P00: 86470 + serial I06/P03: 17968 + eth
<BR>
I04/P01: 197648 + serial I00/P05: 8578913 timer
<BR>
I05/P02: 197648 + sermux I01/P06: 109547 keyboard
<BR>
I06/P03: 17968 + eth I02/P07: 0 + cascade
<BR>
I13/P14: 1 math error I14/P07: 93123 + Ux4F
<BR>
I14/P07: 93123 + Ux4F I13/P14: 1 math error
<BR>
</CODE>
</UL>
<P>
<P><P>
<H3>
<A NAME="__irqtune_41__">So in order to get the best overall system, we may need to change IRQ priority <EM>and</EM> physically change the hardware IRQ configuration?</A>
</H3>
<P>
<STRONG><EM>Exactly</EM></STRONG>.
<P>
Different systems may have highly different criteria for what
is optimum. It is, ultimately, a choice that each system administrator must
make based upon the specific requirements for the particular system in
question. We can only provide tools to do the job, but the final choice
is ultimately decided on a case-by-case basis. There is no
<EM>
one size fits all
</EM>
solution.
<P>
<P><P>
<HR>
<H1>
<A NAME="__irqtune_42__">What about <EM>irqtune</EM> load failures or incompatibilities with kernel revisions?</A>
</H1>
<P>
<P><P>
<H3>
<A NAME="__irqtune_43__">Q: What's the bottom line?</A>
</H3>
<P>
<EM>irqtune</EM> makes every attempt to load its kernel module.
<EM>irqtune</EM> probes the kernel, /proc/ksyms, and <EM>insmod</EM>.
It attempts to detect, correct, or work around any difficulties. If the
problems are truly severe, <EM>irqtune</EM> will report this also.
Normally, <EM>irqtune</EM> probes silently, only reporting the results of
the local system configuration if there's an non-recoverable error.
<P>
<UL>
<LI>
To show what <EM>irqtune</EM> actually checks for each time it's invoked,
here is the full error output (-e) from irqtune:
<BR>
<CODE>
irqtune: version is 0.6
<BR>
irqtune: kernel version 2.0.30
<BR>
probe: irqtune must be invoked via the full path -- OK
<BR>
probe: /sbin in $PATH -- YES
<BR>
probe: insmod found in $PATH (/sbin) -- OK
<BR>
probe: insmod simple execution -- OK
<BR>
probe: insmod has version (2.0.0) -- YES
<BR>
probe: rmmod found in insmod directory -- OK
<BR>
probe: insmod version supports command line options -- OK
<BR>
probe: insmod version (2.0.0) compatible with kernel version (2.0.30) -- OK
<BR>
probe: insmod version should be 2.1.34 (or better) -- WARNING
<BR>
probe: insmod and kernel compatible with CONFIG_MODVERSIONS -- OK
<BR>
probe: irqtune_mod loading will be tried -- OK
<BR>
probe: kernel version irqtune built under (1.0.0) matches current system -- NO
<BR>
probe: kernel IRQ handling is compatible -- OK
<BR>
probe: kernel has module support (CONFIG_MODULES) -- OK
<BR>
probe: kernel has symbols -- OK
<BR>
probe: kernel is using versions (CONFIG_MODVERSIONS) -- NO
<BR>
probe: kernel symbols are checksummed (CONFIG_MODVERSIONS) -- NO
<BR>
probe: kernel has /proc/interrupts -- OK
<BR>
irqtune: simulating IRQ priority of 3/14
<BR>
I00/P05: 8578913 timer
<BR>
I01/P06: 109547 keyboard
<BR>
I02/P07: 0 + cascade
<BR>
I03/P00: 86470 + serial
<BR>
I04/P01: 197648 + serial
<BR>
I11/P12: 197648 + sermux
<BR>
I12/P13: 17968 + eth
<BR>
I13/P14: 1 math error
<BR>
I14/P07: 93123 + Ux4F
<BR>
irqtune: complete
<BR>
</CODE>
<LI>
<EM>irqtune</EM> probes report <STRONG>YES/NO</STRONG> for informative messages.
These may be ignored. <EM>irqtune</EM> will automatically compensate for any
irregularities found.
<BR>
<LI>
<EM>irqtune</EM> probes report <STRONG>OK/WARNING</STRONG> for problems that <STRONG>may</STRONG> prevent
proper operation. These may require changes to the local configuration.
Generally, these may be ignored unless <EM>irqtune</EM> fails to load.
<BR>
<LI>
<EM>irqtune</EM> probes report <STRONG>OK/ERROR</STRONG> for problems that <STRONG>will</STRONG> prevent
proper operation. These will require changes or upgrades to the local
configuration.
<BR>
<LI>
If it is believed that the probes are reporting errors when none actually
exist,
the <STRONG>-f</STRONG> option may be used to force <EM>irqtune</EM> to continue anyway.
<BR>
</UL>
<P>
No matter what happens with probes or loads, <EM>irqtune</EM> will report the final
completion status as its last line: <STRONG>complete</STRONG> or <STRONG>error</STRONG>.
<P>
<P><P>
<H3>
<A NAME="__irqtune_44__">Q: What should be checked first?</A>
</H3>
<UL>
<LI>
If we did a simple installation, we must specify the full pathname, even
if <EM>irqtune</EM> is placed in a directory that is in $PATH. This is required
because <EM>irqtune</EM> uses argv[0] to locate its <STRONG>irqtune_mod.o</STRONG> file.
<BR>
<LI>
<STRONG>/sbin</STRONG> <EM>should</EM> be in $PATH--this is the probable place for
<EM>insmod</EM>. As a convenience, <EM>irqtune</EM> will add <STRONG>/sbin</STRONG> to $PATH
automatically.
<BR>
<LI>
Be sure that the kernel was built with modules support (CONFIG_MODULES)
enabled. <EM>irqtune</EM> will probe for and report this condition.
<BR>
</UL>
<P>
<P><P>
<H3>
<A NAME="__irqtune_45__">Q: What if the current kernel revision is different from the kernel revision in the prebuilt modules?</A>
</H3>
<P>
<STRONG>
This does not matter.
</
