* Jeff Garzik <[email protected]> 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 [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]
