[lkml]   [2003]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: stochastic fair queueing in the elevator [Re: [BENCHMARK] 2.4.20-ck3 / aa / rmap with contest]
    Andrew Morton wrote:

    >Large directories tend to be spread all around the disk anyway. And I've
    >never explicitly tested for any problems which the loss of readahead might
    >have caused ext2. Nor have I tested inode table readahead. Guess I should.
    >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
    readahead seems to be less effective for non-sequential objects. Or at
    least, you don't get the order of magnitude benefit from doing only one
    seek, you only get the better elevator scheduling from having more
    things in the elevator, which isn't such a big gain.

    For the spectators of the thread, one of the things most of us learn
    from experience about readahead is that there has to be something else
    trying to interject seeks into your workload for readahead to make a big
    difference, otherwise a modern disk drive (meaning, not 30 or so years
    old) is going to optimize it for you anyway using its track cache.


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