lkml.org 
[lkml]   [2003]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: stochastic fair queueing in the elevator [Re: [BENCHMARK] 2.4.20-ck3 / aa / rmap with contest]


    Andrea Arcangeli wrote:

    >On Mon, Feb 10, 2003 at 06:41:14PM +1100, Nick Piggin wrote:
    >
    >>Andrea Arcangeli wrote:
    >>
    >>
    >>>On Mon, Feb 10, 2003 at 03:58:26PM +1100, Nick Piggin wrote:
    >>>
    >>>>Remember that readahead gets scaled down quickly if it isn't
    >>>>getting hits. It is also likely to be sequential and in the
    >>>>track buffer, so it is a small cost.
    >>>>
    >>>>Huge readahead is a problem however anticipatory scheduling
    >>>>will hopefully allow good throughput for multiple read streams
    >>>>without requiring much readahead.
    >>>>
    What I mean by this is: if we have >1 sequential readers (eg. ftp
    server), lets say 30MB/s disk, 4ms avg seek+settle+blah time,
    submitting reads in say 128KB chunks alternating between streams
    will cut throughput in half... At 1MB readahead we're at 89%
    throughput. At 2MB, 94%

    With anticipatory scheduling, we can give each stream say 100ms
    so thats 96% with, say... 8K readahead if you like. (Yes, I am
    aware that CPU/PCI/IDE efficiency also mandates a larger request
    size).

    Anyway that is the theory. It remains to be seen if we can make
    it work.

    >>>>
    >>>>
    >>>the main purpose of readahead is to generate 512k scsi commands when you
    >>>read a file with a 4k user buffer, anticipatory scheduling isn't very
    >>>related to readahead.
    >>>
    >>>
    >>You seem to be forgetting things like seek time.
    >>
    >
    >I didn't say it's the only purpose. Of course there's no hope for
    >merging in the metadata dependent reads of the fs where anticipatory
    >scheduling does its best, and infact they don't even attempt to do any
    >readhaead. BTW, one thing that should definitely do readhaead and it's
    >not doing that (at least in 2.4) is the readdir path, again to generate
    >big commands, no matter the seeks. It was lost with the directory in
    >pagecache.
    >
    >Andrea
    >
    >
    >
    >

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:33    [W:0.024 / U:61.396 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site