ICH5 SATA causes high interrupt/system load?

ICH5 SATA causes high interrupt/system load?

[Jurgen Kramer]

Hi,

After reading about problems with ICH5 SATA (Intel 875P) I've
set my BIOS back to normal mode for the SATA controller. So now the SATA
drive appears as hdc instead of hde.

The SATA drive was working in both situations (enhanced/normal) the only
difference is that with normal mode there no high system load caused by
the SATA controller (As I reported in a previous mail).

What's causing the high interrupt count in 'enhanced' mode?

Nb I have seen this on both 2.4.21 and 2.5.73.

Cheers,

Jurgen

Re: ICH5 SATA causes high interrupt/system load?

[Jeff Garzik]

Jurgen Kramer wrote:
> Hi,
> 
> After reading about problems with ICH5 SATA (Intel 875P) I've
> set my BIOS back to normal mode for the SATA controller. So now the SATA
> drive appears as hdc instead of hde.
> 
> The SATA drive was working in both situations (enhanced/normal) the only
> difference is that with normal mode there no high system load caused by
> the SATA controller (As I reported in a previous mail).
> 
> What's causing the high interrupt count in 'enhanced' mode?


Well, in legacy mode (a.k.a. normal), each ATA port (a.k.a. channel 
a.k.a. bus) gets their own interrupt, which is never shared with another 
device.

In native mode (a.k.a. enhanced), two ATA ports share a single PCI 
interrupt.  Further, this interrupt may be shared with any number of 
other PCI devices.

So, high interrupt count is necessarily a worry because you're probably 
seeing a coalescing of multiple interrupt counts into one big one.

	Jeff

Re: ICH5 SATA causes high interrupt/system load?

[Jurgen Kramer]

On Tue, 2003-07-01 at 22:41, Jeff Garzik wrote:
> Well, in legacy mode (a.k.a. normal), each ATA port (a.k.a. channel 
> a.k.a. bus) gets their own interrupt, which is never shared with another 
> device.
> 
> In native mode (a.k.a. enhanced), two ATA ports share a single PCI 
> interrupt.  Further, this interrupt may be shared with any number of 
> other PCI devices.
> 
> So, high interrupt count is necessarily a worry because you're probably 
> seeing a coalescing of multiple interrupt counts into one big one.
> 
> 	Jeff
Hmm, it still looks like this is a driver problem. Because

a) your SCSI-ATA driver doesn't show this behavior..;-)
b) booting to XP also doesn't show this behavior. 

BTW it seems that all ATA ports have their own interrupt:

           CPU0       CPU1
  0:      52132      52728    IO-APIC-edge  timer
  1:          2          2    IO-APIC-edge  keyboard
  2:          0          0          XT-PIC  cascade
  8:          1          0    IO-APIC-edge  rtc
  9:          0          0   IO-APIC-level  acpi
 14:       5062       5316    IO-APIC-edge  ide0
 15:          1          1    IO-APIC-edge  ide1
 16:      43464      43565   IO-APIC-level  usb-uhci, usb-uhci, nvidia
 17:      26180      26194   IO-APIC-level  Intel ICH5
 18:  119342344  119704504   IO-APIC-level  ide2, usb-uhci
 19:       1682       2649   IO-APIC-level  usb-uhci
 21:        460        467   IO-APIC-level  eth0
 22:        576        571   IO-APIC-level  SysKonnect SK-98xx
 23:         18         15   IO-APIC-level  ehci-hcd
NMI:          0          0
LOC:     104773     104781
ERR:          0
MIS:          6

Except ide2 is sharing it's interrupt with a usb controller. Doing
nothing gives:

 20:08:28  up 19 min,  3 users,  load average: 0.08, 0.06, 0.02
75 processes: 74 sleeping, 1 running, 0 zombie, 0 stopped
CPU0 states:   0.5% user  20.2% system    0.0% nice   0.0% iowait  78.2%
idle
CPU1 states:   0.5% user  17.0% system    0.0% nice   0.0% iowait  81.4%
idle
Mem:   515128k av,  187396k used,  327732k free,       0k shrd,   13336k
buff
        45524k active,             118320k inactive
Swap:  787176k av,       0k used,  787176k free                   90804k
cached

With your patch and in XP a have a nice nullish system load.

Greetings,

Jurgen

Re: ICH5 SATA causes high interrupt/system load?

[Jeff Garzik]

Jurgen Kramer wrote:
> BTW it seems that all ATA ports have their own interrupt:
> 
>            CPU0       CPU1
>  14:       5062       5316    IO-APIC-edge  ide0
>  15:          1          1    IO-APIC-edge  ide1
>  16:      43464      43565   IO-APIC-level  usb-uhci, usb-uhci, nvidia
>  17:      26180      26194   IO-APIC-level  Intel ICH5
>  18:  119342344  119704504   IO-APIC-level  ide2, usb-uhci

The interrupt count is definitely high.

WRT the interrupt distribution through, the above is normal.  irq 14 and 
15 are the magic legacy IDE interrupts.  Anything other than 14 and 15 
are (usually) standard shareable PCI interrupts.


>  20:08:28  up 19 min,  3 users,  load average: 0.08, 0.06, 0.02
> 75 processes: 74 sleeping, 1 running, 0 zombie, 0 stopped
> CPU0 states:   0.5% user  20.2% system    0.0% nice   0.0% iowait  78.2%
> idle
> CPU1 states:   0.5% user  17.0% system    0.0% nice   0.0% iowait  81.4%
> idle
> Mem:   515128k av,  187396k used,  327732k free,       0k shrd,   13336k
> buff
>         45524k active,             118320k inactive
> Swap:  787176k av,       0k used,  787176k free                   90804k
> cached
> 
> With your patch and in XP a have a nice nullish system load.

Very strange.  My first guess would be that the drivers/ide driver 
appears unfriendly to shared interrupts.  In certain cases the ATA 
protocol does not offer a single, easy "is this interrupt mine?" test; 
the logic has to be implicitly worked into the driver code.  However, 
normally the drivers/ide driver knows what the heck it is doing, so this 
is quite out of the ordinary.

Perhaps you can fiddle with BIOS settings to get ide2 onto an interrupt 
all by itself, and see if the behavior improves.

	Jeff