[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 11:11:01PM +1100, Nick Piggin wrote:
    > Andrea Arcangeli wrote:
    > >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.
    > >
    > I don't understand it at all. I mean there is no other IO going

    Unfortunately I can't help you understand it, but this is what I found
    with my pratical experience, I found it the first time in my alpha years
    ago when I increased the sym to 512k in early 2.4 then since it could
    break stuff we added the max_sectors again in 2.4. But of course if you
    don't fix readahead there's no way reads can take advantage of these
    lowlevel fixes. I thought I fixed readahead too but I felt it got backed
    out and when I noticed I resurrected it in my tree (see the name of the
    patch ;)

    > >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.
    > >
    > Yes it definately has to be selectable (in fact, in my current
    > version, setting antic_expire = 0 disables it), and Andrew has
    > been working on tuning the non anticipatory version into shape.


    > >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.
    > >
    > It would be easy to anticipate or not based on hints. We could


    > anticipate sync writes if we wanted, lower expire time for sync
    > writes, increase it for async reads. It is really not very
    > complex (although the code needs tidying up).

    this is not the way I thought at it. I'm interested to give an hint
    only to know for sure which are the intermediate sync dependent reads
    (the obvious example is when doing the get_block and walking the
    3 level of inode indirect metadata blocks with big files, or while
    walking the balanced tree in reiserfs), and I'm not interested at all
    about writes. And I would just set an higher timeout when a read that I
    know for sure (thanks to the hint) is "intermdiate" is completed. We can
    use high timeouts there because we know they won't trigger 90% of the
    time, a new dependent read will be always submitted first.

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