public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Martin J. Bligh" <mbligh@aracnet.com>
To: Ron cooper <rcooper@jamesconeyisland.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Gigabit/SMP performance problem
Date: Fri, 03 Jan 2003 13:47:29 -0800	[thread overview]
Message-ID: <26860000.1041630449@flay> (raw)
In-Reply-To: <200301031549.29549.rcooper@jamesconeyisland.com>

>> Dual what Xeon? I presume a P4 thing. Can you cat /proc/interrupts?
>> Are you using the irq_balance code? If so, I think you'll only use
>> 1 cpu to process all the interrupts from each gigabit card. Not that
>> you have much choice, since Intel broke the P4's interrupt routing.
> 
> You got my attention with this statement.  I've have Dual Xeon Prestonias on 
> an I860 chipset (IWill dp400).  cat  /proc/interrupts indeed shows CPU0 as 
> processing all IRQ's instead of sharing them with CPU1 on a 2.4.x kernel.
> 
> Is there a work around for this, or is this *really* a problem?  Some say it 
> might be a problem depending on how many interrupts need to be processed per 
> second.  Others imply that cpu0 catching  the irq's might be a good thing.

Right - depends what you're doing. You can look at irq balance (in 2.5 
or 2.4-ac), but I don't like it as a solution much. Or you could try 
programming the TPR (were some patches floating around). Would be interesting
to get some perf measurments against people using the TPR patches (is more
expensive to set on a P4). Or someone from Intel posted some code recently
that seemed to do more intelligent things, but I haven't had the time to
look closely. If you want to experiment with that, I'm sure people would
be interested in the results.
 
> I happen to have PIII's using VIA chipsets that dont have this issue with 
> proc/interrupts.  This is very annonying, but I wonder if it is worth 
> worrying about.

P3's aren't as brain damaged.

M.


  reply	other threads:[~2003-01-03 21:47 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-03 16:12 Gigabit/SMP performance problem 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 [this message]
2003-01-03 21:20 ` Robert Olsson
2003-01-04  3:33 ` Anton Blanchard
2003-01-06 19:43 ` Jon Fraser
  -- strict thread matches above, loose matches on Subject: below --
2003-01-03 20:25 Avery Fay
2003-01-03 21:19 ` Arjan van de Ven
2003-01-03 21:36 ` Martin J. Bligh
2003-01-03 22:31   ` Andrew Theurer
     [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-06 20:25 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:33 Avery Fay
2003-01-06 20:38 Avery Fay
2003-01-07 18:15 ` Robert Olsson
2003-01-08 12:17 Jon Burgess
2003-01-08 21:12 Feldman, Scott
2003-01-08 21:44 Ronciak, John
2003-01-09 12:49 ` Robert Olsson

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=26860000.1041630449@flay \
    --to=mbligh@aracnet.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rcooper@jamesconeyisland.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox