From: Andrew Morton <akpm@digeo.com>
To: James Harper <james.harper@bigpond.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: SMP and CPU1 not showing interrupts in /proc/interrupts
Date: Sun, 23 Feb 2003 02:21:48 -0800 [thread overview]
Message-ID: <20030223022148.7f71398b.akpm@digeo.com> (raw)
In-Reply-To: <3E589799.3000105@bigpond.com>
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).
next prev parent reply other threads:[~2003-02-23 10:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-23 9:42 James Harper
2003-02-23 10:21 ` Andrew Morton [this message]
2003-02-23 10:52 ` dada1
2003-02-23 13:52 ` Arjan van de Ven
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=20030223022148.7f71398b.akpm@digeo.com \
--to=akpm@digeo.com \
--cc=james.harper@bigpond.com \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®