| From: <zephod@xxxxxxxxxx>
| Date: Tue, 01 May 2007 06:17:05 -0700
[Sorry for the slow reply. I only read the list once in a while.]
| D. Hugh Redelmeier wrote
|
| > Sometimes machines run slowly due to being swamped by unhandled
| > interrupts. It would be interesting to monitor /proc/interrupts to
| > see if this is happening.
|
| I don't know what I'm looking for
That would be a good reason to post your results for us to analyze.
Here's an example from my HP Pavilion a1430n (Athlon x2). It has only
been up for 50 minutes due to some instability that surfaced recently.
CPU0 CPU1
1: 8377 0 Phys-irq-level i8042
7: 0 0 Phys-irq-level parport0
8: 0 0 Phys-irq-level rtc
9: 0 0 Phys-irq-level acpi
12: 105 0 Phys-irq-level i8042
14: 54503 0 Phys-irq-level ide0
17: 1 0 Phys-irq-level ATI IXP
19: 184369 0 Phys-irq-level ohci_hcd:usb1, ohci_hcd:usb2, ehci_hcd:usb3
20: 23823 0 Phys-irq-level peth0
21: 401938 0 Phys-irq-level ohci1394, bttv0
22: 105640 0 Phys-irq-level libata
256: 524111 0 Dynamic-irq-level timer0
257: 84851 0 Dynamic-irq-level resched0
258: 26 0 Dynamic-irq-level callfunc0
259: 0 112101 Dynamic-irq-level resched1
260: 0 123 Dynamic-irq-level callfunc1
261: 0 300198 Dynamic-irq-level timer1
262: 91 0 Dynamic-irq-level xenbus
263: 0 0 Dynamic-irq-level console
NMI: 0 0
LOC: 0 0
ERR: 0
Normally the number of interrupts would be similar for each CPU but I
have disabled the irqbalance service because it was causing problems.
See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225399
(I added comments #64 and #6.8).
| but there are 2 things that I
| noticed about the contents of the /proc/interrupts file:
|
| 1. when I typed 'cat /proc/interrupts' I got a message saying
| something like 'file not terminated correctly'. I don't remember the
| exact wording. It looks like a few characters and the end-of-line are
| missing. I'm guessing that this is no big deal and that cat read the
| file in the middle of an update.
The file is created "on demand". When you try to read from it, the
contents are generated and never actually sit on a disk or the like.
What you are observing does not normally happen. cat reads in 1K
chunks and the only observable cracks ought to be at 1K boundaries
(assuing that /proc/interrupts code locks kernel structures, which might
not be the case). If you want to try to read in one fell swoop, try:
dd if=/proc/interrupts bs=1024k
I would guess that userland is being starved for processor cycles
which could expose some race conditions.
| 2. The LOC line has some large numbers; ~1500000 for each processor.
| This is immediately after boot up,
I don't really know what LOC counts. If you look in the kernel source
tree, in Documentation/filesystems/proc.txt, you will see this brief
sentence:
LOC is the local interrupt counter of the internal APIC of every CPU.
| (Immediate isn't the right word as
| it takes ~45mins to boot and log in) Is this normal?
No.
