lkml.org 
[lkml]   [2004]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRE: 2.6.1 and irq balancing
Date
From
> 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    [W:0.053 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site