All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <piggin@cyberone.com.au>
To: Ethan Weinstein <lists@stinkfoot.org>
Cc: "Nakajima, Jun" <jun.nakajima@intel.com>,
	Ed Tomlinson <edt@aei.ca>,
	linux-kernel@vger.kernel.org, "Kamble,
	Nitin A" <nitin.a.kamble@intel.com>
Subject: Re: 2.6.1 and irq balancing
Date: Tue, 13 Jan 2004 18:05:09 +1100	[thread overview]
Message-ID: <400398A5.9040705@cyberone.com.au> (raw)
In-Reply-To: <40039529.2040709@stinkfoot.org>



Ethan Weinstein wrote:

> Nakajima, Jun wrote:
>
>>> Admittedly, the machine's load was not high when I took this sample.
>>> However, creating a great deal of load does not change these 
>>> statistics at all.  Being that there are patches available for 2.4.x 
>>> kernels to fix this, I don't think this at all by design, but what 
>>> do I know? =)
>>>  
>>
>
>> 2.6 kernels don't need a patch to it as far as I understand. Are you
>> saying that with significant amount of load, you did not see any
>> distribution of interrupts? Today's threshold in the kernel is high
>> because we found moving around interrupts frequently rather hurt the
>> cache and thus lower the performance compared to "do nothing". Can you
>> try to create significant load with your network (eth0 and eh1) and see
>> what happens?
>> Jun 
>
>
> Here's the situation two days later, I created some brief periods of 
> high load on eth1 and I see we have some change:
>
>
>            CPU0       CPU1       CPU2       CPU3
>   0:  184932542          0    2592511          0    IO-APIC-edge  timer
>   1:       1875          0          0          0    IO-APIC-edge  i8042
>   2:          0          0          0          0          XT-PIC  cascade
>   3:    3046103          0          0          0    IO-APIC-edge  serial
>   8:          2          0          0          0    IO-APIC-edge  rtc
>   9:          0          0          0          0   IO-APIC-level  acpi
>  14:         76          0          0          0    IO-APIC-edge  ide0
>  16:    2978264          0          0          0   IO-APIC-level  
> sym53c8xx
>  22:    7838940          0          0          0   IO-APIC-level  eth0
>  48:     916078          0     125150          0   IO-APIC-level  aic79xx
>  49:    1099375          0          0          0   IO-APIC-level  aic79xx
>  54:   51484241        316   50560879        279   IO-APIC-level  eth1
> NMI:          0          0          0          0
> LOC:  187530735  187530988  187530981  187530986
> ERR:          0
> MIS:          0
>


Aside from the obvious imbalance between physical CPUs:
I think interrupts should be much more freely balanced between siblings
that share cache, otherwise process a running on CPU0 gets less time than
process b running on CPU1 because of the interrupt load.


>
> My argument is (see below).  This is an old 2x pentium2 @400, also 
> running 2.6, an old Compaq Proliant to be exact.  This machine 
> obviously has no HT, so why the balanced load?


IIRC the P2/3 APICs are set to a round robin delivery mode while the P4
ones are not. It is still not ideal though, while you have fairness, you now
have suboptimal performance.



  reply	other threads:[~2004-01-13  7:12 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-11 23:59 2.6.1 and irq balancing Nakajima, Jun
2004-01-12  4:42 ` Bill Davidsen
2004-01-12 14:06   ` Zwane Mwaikambo
2004-01-12 16:10   ` Martin J. Bligh
2004-01-13  6:50 ` Ethan Weinstein
2004-01-13  7:05   ` Nick Piggin [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-01-13  8:09 Nakajima, Jun
2004-01-13  7:57 Nakajima, Jun
2004-01-10 23:14 Ethan Weinstein
2004-01-11  2:39 ` Ed Tomlinson
2004-01-11  3:38   ` Nick Piggin
2004-01-11  9:52     ` Arjan van de Ven
2004-01-11  5:19   ` Ethan Weinstein
2004-01-11  9:51 ` Arjan van de Ven
2004-01-11 16:50   ` Joe Korty
2004-01-11 18:19     ` Arjan van de Ven
2004-01-15 11:43     ` Pavel Machek
2004-01-11 13:14 ` Martin Schlemmer

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=400398A5.9040705@cyberone.com.au \
    --to=piggin@cyberone.com.au \
    --cc=edt@aei.ca \
    --cc=jun.nakajima@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lists@stinkfoot.org \
    --cc=nitin.a.kamble@intel.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 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.