It seems like the timer generates most of the interrupts, which makes
sense. But can it possibly be the reason for the 30% usage?
Anyways, since I'm a bit unfamiliar with the /proc/interrupts format:
CPU0
0: 6772583 IO-APIC-edge timer
1: 4929 IO-APIC-edge i8042
7: 3 IO-APIC-edge parport0
8: 1 IO-APIC-edge rtc
9: 0 IO-APIC-level acpi
14: 52691 IO-APIC-edge ide0
15: 242905 IO-APIC-edge ide1
169: 1006942 IO-APIC-level eth0
185: 53538 IO-APIC-level uhci_hcd:usb1, uhci_hcd:usb2,
uhci_hcd:usb3, ehci_hcd:usb4
193: 724 IO-APIC-level EMU10K1
201: 2089405 IO-APIC-level nvidia
NMI: 0
LOC: 6772539
ERR: 0
MIS: 0
Thanks,
- Itay.
On 11/24/06, Ori Idan <[EMAIL PROTECTED]> wrote:
you probably mean 'watch -d cat /proc/interrupts'
On 11/24/06, Oren Held <[EMAIL PROTECTED]> wrote:
>
> Yo man,
>
> Is running 'watch -d /proc/interrupts' giving some additional
> information WHAT causes the interrupts?
>
> Itay Duvdevani wrote:
> > Hello all,
> >
> > Running a Debian-testing (2.6.17-2-k7 stock kernel) system, I'm
> > experiencing recently high software-interrupt loads.
> >
> > SI loads can get as high as 30% or as "low" as 5%, but almost never
> > below, all in idle system load.
> >
> > Looking at another systems, I see SI load of... 0%.
> >
> > What can cause this high load? It's quite frustrating to know third of
> > you CPU goes on software-interrupts... It might convince me switching
> > to an SMP machine :)
> >
> > Thanks!
> >
>
>
>
=================================================================
> To unsubscribe, send mail to [EMAIL PROTECTED] with
> the word "unsubscribe" in the message body, e.g., run the command
> echo unsubscribe | mail [EMAIL PROTECTED]
>
>
--
- duvduv
--
- duvduv
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
