Re: libata/sata_nv latency on NVIDIA CK804 [was Re: AMD64 X2 lostticks on PM timer]

From: Jeff Garzik
Date: Wed Mar 15 2006 - 17:28:00 EST


Ingo Molnar wrote:
* Bill Rugolsky Jr. <brugolsky@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:


<...>-2913 0d.h. 8us : raise_softirq_irqoff (blk_complete_request)
<...>-2913 0d.h. 8us : __ata_qc_complete (ata_qc_complete)
<...>-2913 0d.h. 9us : ata_host_intr (nv_interrupt)
<...>-2913 0d.h. 9us!: ata_bmdma_status (ata_host_intr)
<...>-2913 0d.h. 16641us : nv_check_hotplug_ck804 (nv_interrupt)
<...>-2913 0d.h. 16642us : _spin_unlock_irqrestore (nv_interrupt)
<...>-2913 0d.h. 16642us : smp_apic_timer_interrupt (apic_timer_interrupt)
<...>-2913 0d.h. 16642us : exit_idle (smp_apic_timer_interrupt)


ouch. The codepath in question (ata_host_intr()) doesnt seem to have any loop that could take 16.6 msecs (!). This very much looks like some hardware-triggered delay - some really screwed up DMA prioritization perhaps, starving the host CPU for 16.6 msecs? But what DMA takes 16.6 msecs? That's enough time to transfer dozens of megabytes of data on a midrange system.

Yeah, I don't see anything offhand either.

sata_nv's nv_interrupt() should be using spin_lock() rather than spin_lock_irqsave(), but I doubt that's a latency cause.

I would be surprised if the legacy PCI IDE registers, all PIO-based, would be implemented via BIOS SMM or some other similarly slow method. But its not impossible...

Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/