lkml.org 
[lkml]   [2004]   [Jan]   [13]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
SubjectRE: 2.6.1 and irq balancing
DateTue, 13 Jan 2004 00:09:59 -0800
From"Nakajima, Jun" <>
> 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.
>
That scheduling issue is true. Today we balance interrupt load on a
package (i.e. physical CPU) basis, and we don't care which logical
processors do the interrupt handling because it should not matter in
terms of performance. 

Jun

> -----Original Message-----
> From: Nick Piggin [mailto:piggin@cyberone.com.au]
> Sent: Monday, January 12, 2004 11:05 PM
> To: Ethan Weinstein
> Cc: Nakajima, Jun; Ed Tomlinson; linux-kernel@vger.kernel.org; Kamble,
> Nitin A
> Subject: Re: 2.6.1 and irq balancing
> 
> 
> 
> 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.
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:00    [from the cache]
©2003-2008