lkml.org 
[lkml]   [2006]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: libata/sata_nv latency on NVIDIA CK804 [was Re: AMD64 X2 lost ticks on PM timer]
    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.

    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. Status checks
    for example (ata_busy_wait in libata.h) are basically

    while (ioreadX() != condition)
    udelay(10)

    That delay is mainly a "don't pound too hard on the hardware" delay. If
    the hardware is really slow completing a command after signalling
    completion, you'll potentially wait up to 1000*10 us in some cases. And
    there are other delays, such as the per-command ndelay() plus ioread().

    Welcome to the wonderful world of IDE.

    Jeff


    -
    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:25    [W:0.023 / U:0.084 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site