Ingo Molnar wrote:
* Bill Rugolsky Jr. <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
