On Fri, Jun 21, 2002 at 12:48:31AM +0200, J.A. Magallon wrote:
>
> On 2002.06.20 Andrea Arcangeli wrote:
> >
> >Also merges some stuff from 19pre10jam2, not all the same, in particular
> >irq-balance is quite different, previous algorithm looked not really
> >good while auditing it, benchmarks will tell, any feedback on this in
> >particular would be welcome. Have a look at xosview to see the
> >difference.
> >
>
> Still not tested on the dual xeon, but on a BX with doal PII:
> werewolf:~# cat /proc/interrupts
> CPU0 CPU1
> 0: 83491 63920 IO-APIC-edge timer
> 1: 2044 1213 IO-APIC-edge keyboard
> 2: 0 0 XT-PIC cascade
> 5: 1 1 IO-APIC-level bttv
> 8: 0 1 IO-APIC-edge rtc
> 10: 52335 24289 IO-APIC-level aic7xxx, EMU10K1
> 11: 69049 50801 IO-APIC-level eth0, nvidia
> 12: 33155 23661 IO-APIC-edge PS/2 Mouse
> 14: 2 14 IO-APIC-edge ide0
> 15: 3 13 IO-APIC-edge ide1
> NMI: 0 0
> LOC: 147281 147325
> ERR: 0
> MIS: 36
>
> Old patch, on the dual P4Xeon box:
> werewolf:~> ssh annwn cat /proc/interrupts
> CPU0 CPU1 CPU2 CPU3
> 0: 3302667 3295991 3299383 3299984 IO-APIC-edge timer
> 1: 4813 4680 4796 4846 IO-APIC-edge keyboard
> 2: 0 0 0 0 XT-PIC cascade
> 8: 1 0 0 0 IO-APIC-edge rtc
> 12: 64959 64803 65238 63623 IO-APIC-edge PS/2 Mouse
> 16: 65038 66347 60169 67167 IO-APIC-level e100
> 17: 0 0 0 0 IO-APIC-level Intel ICH2
> 18: 529910 524941 535660 535544 IO-APIC-level aic7xxx, eth2
> 19: 71883 71973 72540 72460 IO-APIC-level usb-uhci, eth0
> 22: 2497022 2491901 2495182 2495298 IO-APIC-level nvidia
> 23: 0 0 0 0 IO-APIC-level usb-uhci
> NMI: 0 0 0 0
> LOC: 13198438 13198374 13198440 13198453
> ERR: 0
> MIS: 0
>
> I think the old one looks much better... ;)
I think you're missing, the more irq you get in the same cpu the better.
You're wasting tons of icache for no good reason. It's an illusion that
seeing the number distributed is a good thing. With the foster the bad
thing is that all irqs are delivered to the same cpu, so the load cannot
scale, but for any benchmark (at least before my patch) you should use
irq binding to avoid wasting icache, now with my logic maybe we can rely
on the random distribution under load, and on the idle cpu distribution
in multiway and in general in workloads with sometime idle cpus.
Andrea
-
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/
This archive was generated by hypermail 2b29 : Sun Jun 23 2002 - 22:00:24 EST