[lkml]   [2001]   [Oct]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: xmm2 - monitor Linux MM active/inactive lists graphically
    > In contrast, the -ac logic says roughly "Who the hell cares if the driver
    > can merge requests or not, we can just give it thousands of small requests
    > instead, and cap the total number of _sectors_ instead of capping the
    > total number of requests earlier"

    If you think about it the major resource constraint is sectors - or another
    way to think of it "number of pinned pages the VM cannot rescue until the
    I/O is done". We also have many devices where the latency is horribly
    important - IDE is one because it lacks sensible overlapping I/O. I'm less
    sure what the latency trade offs are. Less commands means less turnarounds
    so there is counterbalance.

    In the case of IDE the -ac tree will do basically the same merging - the
    limitations on IDE DMA are pretty reasonable. DMA IDE has scatter gather
    tables and is actually smarter than many older scsi controllers. The IDE
    layer supports up to 128 chunks of up to just under 64Kb (should be 64K
    but some chipsets get 64K = 0 wrong and its not pretty)

    > In my opinion, the -ac logic is really bad, but one thing it does allow is
    > for stupid drivers that look like high-performance drivers. Which may be
    > why it got implemented.

    Well I'm all for making dumb hardware go as fast as smart stuff but that
    wasn't the original goal - the original goal was to fix the bad behaviour
    with the base kernel and large I/O queues to slow devices like M/O disks.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:11    [W:3.310 / U:0.348 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site