[lkml]   [2003]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: RFC on io-stalls patch
    On Sun, Jul 13, 2003 at 11:01:16AM +0200, Jens Axboe wrote:
    > No I don't have anything specific, it just seems like a bad heuristic to
    > get rid of. I can try and do some testing tomorrow. I do feel strongly

    well, it's not an heuristic, it's a simplification and it will certainly
    won't provide any benefit (besides saving some hundred kbytes of ram per
    harddisk that is a minor benefit).

    > that we should at least make sure to reserve a few requests for reads
    > exclusively, even if you don't agree with the oversized check. Anything
    > else really contradicts all the io testing we have done the past years
    > that shows how important it is to get a read in ASAP. And doing that in

    Important for latency or throughput? Do you know which is the benchmarks
    that returned better results with the two queues, what's the theory
    behind this?

    > the middle of 2.4.22-pre is a mistake imo, if you don't have numbers to
    > show that it doesn't matter for the quick service of reads.

    Is it latency or throughput that you're mainly worried about? Latency
    certainly isn't worse with this lowlatency improvement (no matter one or
    two queues, that's a very minor issue w.r.t. to latency).

    I could imagine readahead throughput could be less likely to be hurted
    by writes with the two queue. But I doubt it's very noticeable.

    However I'm not against re-adding it, clearly there's a slight benefit
    for reads in never blocking in wait_for_request, I just didn't consider
    it very worthwhile since they've to block anyways later normally for
    batch_sectors anyways, just like every write (in a congested I/O
    subsystem - when the I/O isn't congested nothing blocks in the 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:46    [W:4.942 / U:0.048 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site