lkml.org 
[lkml]   [2003]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: SMP and CPU1 not showing interrupts in /proc/interrupts
James Harper <james.harper@bigpond.com> wrote:
>
> somewhere between about 2.5.53 and 2.5.62 my /proc/interrupts has gone
> from an approximately even distribution of interrupts between CPU0 and
> CPU1 to grossly uneven:
>
> CPU0 CPU1
> 0: 13223321 2233217 IO-APIC-edge timer
> 1: 13442 0 IO-APIC-edge i8042
> 2: 0 0 XT-PIC cascade
> 3: 291874 0 IO-APIC-edge serial
> 8: 3 0 IO-APIC-edge rtc
> 9: 0 0 IO-APIC-edge acpi
> 14: 18932 0 IO-APIC-edge ide0
> 15: 14 0 IO-APIC-edge ide1
> 16: 190607 1 IO-APIC-level eth0, nvidia
> 17: 3214 0 IO-APIC-level bttv0
> 18: 14249 1 IO-APIC-level ide2
> 19: 121942 0 IO-APIC-level uhci-hcd, wlan0
> NMI: 0 0
> LOC: 15458218 15458423
> ERR: 0
> MIS: 0
>
> if i really hit the system hard then CPU1 will start accruing interrupts
> but in a mostly idle state CPU1 just sits on its bum and lets CPU0
> handle them all, with the exception of irq #0, for some reason.
>

That is a deliberate part of the new interrupt balancing code.

If the interrupt rate is low, it is better to keep all the interrupt
processing code and data in the cache of a single CPU.

It is only if that CPU starts to run out of steam that it is worthwhile
taking the hit of getting other CPUs to service interrupts as well.

(I think. At least, it sounds good and the benchmarks came out well).

-
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 13:33    [W:0.038 / U:0.768 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site