On Saturday, February 12, 2011 12:55:12 pm M. Fioretti wrote:
On Sat, Feb 12, 2011 12:47:13 PM -0600, Rick Sewill
(rsewill(a)gmail.com)
wrote:
> Could you show us the output of twice, the second time a few
seconds
> after the first time so we can see if any interrupt number changes fast.
> more /proc/interrupts
here are two runs, 5/6 seconds apart:
[root@polaris ~]# more /proc/interrupts
CPU0 CPU1
0: 136 180 IO-APIC-edge timer
1: 0 2 IO-APIC-edge i8042
4: 0 2 IO-APIC-edge
7: 1 0 IO-APIC-edge parport0
8: 0 1 IO-APIC-edge rtc0
9: 0 0 IO-APIC-fasteoi acpi
12: 0 4 IO-APIC-edge i8042
14: 0 0 IO-APIC-edge pata_amd
15: 0 0 IO-APIC-edge pata_amd
17: 0 2 IO-APIC-fasteoi firewire_ohci
20: 116972 135 IO-APIC-fasteoi ohci_hcd:usb3, nvidia
21: 947 289 IO-APIC-fasteoi ehci_hcd:usb2, hda_intel
22: 0 3 IO-APIC-fasteoi ehci_hcd:usb1
23: 252957 24 IO-APIC-fasteoi ohci_hcd:usb4
43: 449718 5490 PCI-MSI-edge ahci
44: 850242 23 PCI-MSI-edge eth0
NMI: 0 0 Non-maskable interrupts
LOC: 12772218 13583547 Local timer interrupts
SPU: 0 0 Spurious interrupts
PMI: 0 0 Performance monitoring interrupts
PND: 0 0 Performance pending work
RES: 6896487 7547957 Rescheduling interrupts
CAL: 8607 11701 Function call interrupts
TLB: 43915 42920 TLB shootdowns
TRM: 0 0 Thermal event interrupts
THR: 0 0 Threshold APIC interrupts
MCE: 0 0 Machine check exceptions
MCP: 103 103 Machine check polls
ERR: 1
MIS: 0
[root@polaris ~]#
[root@polaris ~]# more /proc/interrupts
CPU0 CPU1
0: 136 180 IO-APIC-edge timer
1: 0 2 IO-APIC-edge i8042
4: 0 2 IO-APIC-edge
7: 1 0 IO-APIC-edge parport0
8: 0 1 IO-APIC-edge rtc0
9: 0 0 IO-APIC-fasteoi acpi
12: 0 4 IO-APIC-edge i8042
14: 0 0 IO-APIC-edge pata_amd
15: 0 0 IO-APIC-edge pata_amd
17: 0 2 IO-APIC-fasteoi firewire_ohci
20: 116985 135 IO-APIC-fasteoi ohci_hcd:usb3, nvidia
21: 947 289 IO-APIC-fasteoi ehci_hcd:usb2, hda_intel
22: 0 3 IO-APIC-fasteoi ehci_hcd:usb1
23: 252957 24 IO-APIC-fasteoi ohci_hcd:usb4
43: 449809 5490 PCI-MSI-edge ahci
44: 850456 23 PCI-MSI-edge eth0
NMI: 0 0 Non-maskable interrupts
LOC: 12774821 13585530 Local timer interrupts
SPU: 0 0 Spurious interrupts
PMI: 0 0 Performance monitoring interrupts
PND: 0 0 Performance pending work
RES: 6896974 7548786 Rescheduling interrupts
CAL: 8608 11703 Function call interrupts
TLB: 43919 42921 TLB shootdowns
TRM: 0 0 Thermal event interrupts
THR: 0 0 Threshold APIC interrupts
MCE: 0 0 Machine check exceptions
MCP: 103 103 Machine check polls
ERR: 1
MIS: 0
[root@polaris ~]#
will try now to find out the clock interrupt rate. Thanks
I think the clock interrupt rate is shown by the "Local timer interrupts".
I don't know if that number is okay or not. I think it might be okay.
I am curious about the Rescheduling interrupts.
I do not have a dual core system so I have no rescheduling interrupts.
I do not know how many rescheduling interrupts is too many.
I did google searches, "Resheduling interrupts"
and Linux "Resheduling interrupts"
It appears there have been problems, in this area, over the years.
We should be careful to limit ourselves to any recent problems.
I found some sort of explanation of rescheduling interrupts at
https://help.ubuntu.com/community/ReschedulingInterrupts
Also at this URL were suggestions for troubleshooting problems.
One suggestion, from this URL was to use "vmstat 1".
I haven't used vmstat before so this is educational.
Another suggestion was troubleshooting ACPI and APIC problems.
This problem sounds similar to another person's problem:
http://www.spinics.net/lists/kvm/msg49558.html
I mention this problem because of the date and also it's
Debian (not Fedora). We don't know if this person's problem
is a "Rescheduling interrupt" problem...but it sounds similar.