![]() | |||||||||||||
Messages in this thread |
* Jeff Garzik <jeff@garzik.org> wrote: > Ingo Molnar wrote: > >in this particular case there's only very simple (and non-IO) > >instructions in that codepath (no loops either), except for > >ata_bmdma_status() which does IO ops: so i agree with you that the most > >likely candidate for the delay is the readb() or the inb() in > >ata_bdma_status(). > > > >I'm wondering which one of the two. inb()s are known to be horrible on > >some systems - but i've never seen them take 16 milliseconds. If it's > >the inb(), then that could also involve SMM mode and IO > > > ata_bmdma_status() is just a single IO read, and even 1ms is highly > improbable. well, it's a PIO inb() op i think, and could thus in theory trigger SMM BIOS code. > I'd look elsewhere. There are a ton of udelay() calls in the legacy > PCI IDE BMDMA code paths (sata_nv uses these), so I'm not surprised > there is latency in general, in a libata+sata_nv configuration. [...] they would show up in the latency trace ... the latency trace is very clear, and in the previous mail i described the precise codepath where we observed the latency. Only that single PIO read is there AFAICS. 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 22:29 [from the cache] ©2003-2008 | |||||||||||||