![]() | |||||||||||||
Messages in this thread |
* Jeff Garzik <jeff@garzik.org> wrote: > Ingo Molnar wrote:> >* Bill Rugolsky Jr. <brugolsky@telemetry-investments.com> 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. please see my previous codepath description. No spin_lock() calls in the measured codepath. They would show up in the latency trace anyway. > 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... yeah. But then again - PIO ops easily take 16 usecs on almost arbitrary PC hardware, so an SMM trap might not be all that noticeable - especially if this register is considered legacy. (maybe Windows does the MMIO variant) Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2006-03-15 23:40 [from the cache] ©2003-2008 | |||||||||||||