From: "Martin J. Bligh" <mbligh@aracnet.com>
To: Avery Fay <avery_fay@symantec.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Gigabit/SMP performance problem
Date: Fri, 03 Jan 2003 13:36:26 -0800 [thread overview]
Message-ID: <23880000.1041629786@flay> (raw)
In-Reply-To: <OF256CD297.9F92C038-ON85256CA3.006A4034-85256CA3.00705DEA@symantec.com>
> Dual Pentium 4 Xeon at 2.4 Ghz. I believe I am using irq load balancing as
> shown below (seems to be applied to Red Hat's kernel). Here's
> /proc/interrupts:
Is in 2.4.20-ac2 at least. See if arch/i386/kernel/io_apic.c
has a function called balance_irq.
> CPU0 CPU1
> 0: 179670 182501 IO-APIC-edge timer
> 1: 386 388 IO-APIC-edge keyboard
> 2: 0 0 XT-PIC cascade
> 8: 1 0 IO-APIC-edge rtc
> 12: 9 9 IO-APIC-edge PS/2 Mouse
> 14: 1698 1511 IO-APIC-edge ide0
> 24: 1300174 1298071 IO-APIC-level eth2
> 25: 1935085 1935625 IO-APIC-level eth3
> 28: 1162013 1162734 IO-APIC-level eth4
> 29: 1971246 1967758 IO-APIC-level eth5
> 48: 2753990 2753821 IO-APIC-level eth0
> 49: 2047386 2043894 IO-APIC-level eth1
> 72: 838987 841143 IO-APIC-level eth6
> 73: 2767885 2768307 IO-APIC-level eth7
> NMI: 0 0
> LOC: 362009 362008
> ERR: 0
> MIS: 0
>
> I started traffic at different times on the various interfaces so the
> number of interrupts per interface aren't uniform.
>
> I modified RxIntDelay, TxIntDelay, RxAbsIntDelay, TxAbsIntDelay,
> FlowControl, RxDescriptors, TxDescriptors. Increasing the various
> IntDelays seemed to improve performance slightly.
Makes sense, increasing the delays should reduce the interrupt load.
> I'm using 3 Intel PRO/1000 MT Dual Port Server adapters as well as 2
> onboard Intel PRO/1000 ports. The adapters use the 82546EB chips. I
> believe that the onboard ports use the same although I'm not sure.
>
> Should I get rid of IRQ load balancing? And what do you mean
> "Intel broke the P4's interrupt routing"?
P3's distributed interrupts round-robin amongst cpus. P4's send
everything to CPU 0. If you put irq_balance on, it'll spread
them around, but any given interrupt is still only handled by
one CPU (as far as I understand the code). If you hammer one
adaptor, does that generate more interrupts than 1 cpu can handle?
(turn irq balance off by sticking a return at the top of balance_irq,
and hammer one link, see how much CPU power that burns).
M.
next prev parent reply other threads:[~2003-01-03 21:34 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-03 20:25 Gigabit/SMP performance problem Avery Fay
2003-01-03 21:19 ` Arjan van de Ven
2003-01-03 21:36 ` Martin J. Bligh [this message]
2003-01-03 22:31 ` Andrew Theurer
-- strict thread matches above, loose matches on Subject: below --
2003-01-08 21:44 Ronciak, John
2003-01-09 12:49 ` Robert Olsson
2003-01-08 21:12 Feldman, Scott
2003-01-08 12:17 Jon Burgess
2003-01-06 20:38 Avery Fay
2003-01-07 18:15 ` Robert Olsson
2003-01-06 20:33 Avery Fay
2003-01-06 20:29 Avery Fay
2003-01-06 21:23 ` Martin J. Bligh
2003-01-07 17:19 ` Mike Black
2003-01-06 20:25 Avery Fay
[not found] <b8ce5e32.0301040439.7bdaa903@posting.google.com>
2003-01-06 18:27 ` Bill Davidsen
2003-01-06 19:09 ` Daniel Blueman
2003-01-06 19:26 ` Brian Tinsley
2003-01-03 16:12 Avery Fay
2003-01-03 18:05 ` Martin J. Bligh
2003-01-03 21:49 ` Ron cooper
2003-01-03 21:47 ` Martin J. Bligh
2003-01-03 21:20 ` Robert Olsson
2003-01-04 3:33 ` Anton Blanchard
2003-01-06 19:43 ` Jon Fraser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=23880000.1041629786@flay \
--to=mbligh@aracnet.com \
--cc=avery_fay@symantec.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.