[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 03:58:13PM +0300, Hans Reiser wrote:
    > Is the following a fair summary?
    > There is a certain minimum size required for the IOs to be cost
    > effective. This can be determined by single reader benchmarking. Only
    > readahead and not anticipatory scheduling addresses that.
    > Anticipatory scheduling does not address the application that spends one
    > minute processing every read that it makes. Readahead does.
    > Anticipatory scheduling does address the application that reads multiple
    > files that are near each other (because they are in the same directory),
    > and current readahead implementations (excepting reiser4 in progress
    > vaporware) do not.
    > Anticipatory scheduling can do a better job of avoiding unnecessary
    > reads for workloads with small time gaps between reads than readahead
    > (it is potentially more accurate for some workloads).
    > Is this a fair summary?

    I would also add what I feel the most important thing, that is
    anticipatory scheduling can help decreasing a lot the latencies of
    filesystem reads in presence of lots of misc I/O, by knowing which are
    the read commands that are intermediate-dependent-sync, that means
    knowing a new dependent read will be submitted very quickly as soon as
    the current read-I/O is completed. In such a case it makes lots sense to
    wait for the next read to be submitted instead of start processing
    immediatly the rest of the I/O queue. This way when you read a file and
    you've to walk the indirect blocks before being able to read the data,
    you won't be greatly peanalized against the writes or reads that won't
    need to pass through metadata I/O before being served.

    This doesn't obviate the need of SFQ for the patological multimedia
    cases where I/O latency is the first prio, or for workloads where
    sync-write latency is the first prio.

    BTW, I'm also thinking that the SFQ could be selected not system wide,
    but per-process basis, with a prctl or something, so you could have all
    the I/O going into the single default async-io queue, except for mplayer
    that will use the SFQ queues. This may not even need to be privilegied
    since SFQ is fair and if an user can write a lot it can just hurt
    latency, with SFQ could hurt more but still not deadlock. This SFQ prctl
    for the I/O scheduler, would be very similar to the RT policy for the
    main process scheduler. Infact it maybe the best to just have SFQ always
    enabled, and selectable only via the SFQ prctl, and to enable the
    functionaltiy only per-process basis rather than global. We can still
    add a sysctl to enable it globally despite nobody set the per-process

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