[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.
    On Mon, Feb 10, 2003 at 03:49:59PM +0100, Giuliano Pochini wrote:
    > >> You can wait 10 minutes and still such command can't grow. This is why
    > >> claiming anticipatory scheduling can decrease the need for readahead
    > >> doesn't make much sense to me, there are important things you just can't
    > >> achieve by only waiting.
    > >>
    > >
    > > The anticipatory scheduler can easily permit 512k of reading before seeking
    > > away to another file. In fact it can allow much more, without requiring that
    > > readhead be cranked up.
    > IMHO anticipatory scheduling and readahead address different problems. RA is
    > simpler and cheaper. Reading a few more KB comes almost for free and that
    > helps a lot sequential reads. AS is useful for random i/o (fs metadata,
    > executables, ...), but it wastes time if the timer expires, or if the new
    > request wants data which is far away the previous one. AS is useful for


    > sequential reads too, but only if the application reads large chunks of
    > data, otherwise RA is better. I we need both RA and AS to address the

    actually even if the app reads large chunks of data RA is needed, the
    size of the read/io_submit syscalls won't reach the
    readpage/wait_on_page at the pagecache layer, w/o readahead we would
    read PAGE_SIZE per dma and not more (ignoring PAGE_CACHE_SIZE of course,
    which isn't going to be enough anyways due mem fragmentation issues)

    > largest variety of workloads.
    > Bye.

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