LINUX MINT interrupts: why so many rescheduling interrupts ?

[linuxaomi]

Using LINUX MINT along with XAMPP seems to be a perfect combination.
As I am monitoring most of relevant aspects from different fields (PHP, apache, MySQL, disks, network amm.) there is a question from my side regarding interrupts: cat /proc/interrupts Why so many RES rescheduling interrupts ?

I am complaining about poor responsetime or slowdowns just the high numbers make me thinking.

Thank you

[linuxaomi]

I am NOT complaining about poor responsetime or slowdowns just the high numbers make me thinking.

Sorry for my mistake

[rubberman]

What is the actual output for RES? Rescheduling interrupts occur frequently due to scheduling priority issues. Example: my Scientific Linux 6 (RHEL 6 clone) after 11 days uptime has 400-500K RES events for each of 8 cores - about 4M in total. There are about 3x as many function call interrupts (CAL), and a fair number more TLB shootdowns (TLB). So, without some real numbers, there isn't much we can say about whether or not your system is performing abnormally. In sum, please post the following information:

1. uptime
2. full output of the "cat /proc/interrupts" command

[linuxaomi]

rubberman, your quick response is highly appreciated.
Here you are: uptime and cat /proc/interrupts output

uptime
16:52:57 up 10:34, 2 users, load average: 0.57, 0.78, 0.79

cat /proc/interrupts
CPU0 CPU1
0: 4195377 4213713 IO-APIC-edge timer
1: 12162 11789 IO-APIC-edge i8042
8: 0 1 IO-APIC-edge rtc0
9: 36839 36525 IO-APIC-fasteoi acpi
12: 4036 3950 IO-APIC-edge i8042
16: 0 0 IO-APIC-fasteoi uhci_hcd:usb3
17: 33402 32595 IO-APIC-fasteoi uhci_hcd:usb4, HDA Intel
18: 0 0 IO-APIC-fasteoi uhci_hcd:usb5, uhci_hcd:usb8
19: 0 0 IO-APIC-fasteoi ehci_hcd:usb1
20: 216137 210786 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb6
22: 0 0 IO-APIC-fasteoi uhci_hcd:usb7
29: 389402 379444 PCI-MSI-edge ahci
30: 76870 76299 PCI-MSI-edge i915
31: 0 1 PCI-MSI-edge eth0
32: 920360 851211 PCI-MSI-edge iwlagn
NMI: 0 0 Non-maskable interrupts
LOC: 3273123 3155698 Local timer interrupts
SPU: 0 0 Spurious interrupts
CNT: 0 0 Performance counter interrupts
PND: 0 0 Performance pending work
RES: 1544668 1579553 Rescheduling interrupts
CAL: 208 210 Function call interrupts
TLB: 285553 314723 TLB shootdowns
TRM: 0 0 Thermal event interrupts
THR: 0 0 Threshold APIC interrupts
MCE: 0 0 Machine check exceptions
MCP: 127 127 Machine check polls
ERR: 0
MIS: 0

The ratio between RES/CAL/TLB is much different from yours. And let me point out this once again, I am happy with overall performance.

[rubberman]

Well, if performance is not impacted, then probably this is not an issue. As they say, if it ain't broke, don't try to fix it! :-) Honestly, scheduling interrupts are largely dependent upon the schedulers you are using, and load factors that I cannot know about.

[linuxaomi]

Interesting, I understand that schedulers i.e. crontab and time driven MySQL procedures are contributing to that kind of activities. Mostly I am using this PC for development and testing. Running php scricts again and again.
As I am expecting less workload in production I don't feel concerned about it at all. And you are right, don't touch/break it unless there would be a reason to react.

Many thanks,
linuxaomi

[linuxaomi]

Part of AoMi realtime monitor reveals frequent MySQL events. Time driven events. http://notebook.linuxaomi.operaunite.com/localhost/aomi/127.0.0.1_127.0.0.1_nrg8_linux_mysql_events.png

[linuxaomi]

Part of AoMi realtime monitor reveals frequent LINUX crontab events. Time driven events.

http://notebook.linuxaomi.operaunite.com/localhost/aomi/127.0.0.1_127.0.0.1_nrg8_linux_schedule.png