[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]
    On Mon, Feb 10, 2003 at 10:45:59PM +1100, Nick Piggin wrote:
    > perspective it does nullify the need for readahead (though
    > it is obivously still needed for other reasons).

    I'm guessing that physically it may be needed from a head prospective
    too, I doubt it only has to do with the in-core overhead. Seeing it all
    before reaching the seek point might allow the disk to do smarter things
    and to keep the head at the right place for longer, dunno. Anyways,
    whatever is the reason it doesn't make much difference from our point of
    view ;), but I don't expect this hardware behaviour changing in future
    high end storage.

    NOTE: just to be sure, I'm not at all against anticpiatory scheduling,
    it's clearly a very good feature to have (still I would like an option
    to disable it especially in heavy async environments like databases,
    where lots of writes are sync too) but it should be probably be enabled
    by default, especially for the metadata reads that have to be
    synchronous by design.

    Infact I wonder that it may be interesting to also make it optionally
    controlled from a fs hint (of course we don't pretend all fs to provide
    the hint), so that you stall I/O writes only when you know for sure
    you're going to submit another read in a few usec, just the time to
    parse the last metadata you read. Still a timeout would be needed for
    scheduling against RT etc..., but it could be a much more relaxed
    timeout with this option enabled, so it would need less accurate
    timings, and it would be less dependent on hardware, and it would
    be less prone to generate false positive stalls. The downside is having
    to add the hints.

    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.022 / U:4.188 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site