lkml.org 
[lkml]   [2001]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.4.6-pre2, pre3 VM Behavior
    On Thu, 14 Jun 2001, John Stoffel wrote:

    > Rik> There's another issue. If dirty data is written out in small
    > Rik> bunches, that means we have to write out the dirty data more
    > Rik> often.
    >
    > What do you consider a small bunch? 32k? 1Mb? 1% of buffer space?
    > I don't see how delaying writes until the buffer is almost full really
    > helps us. As the buffer fills, the pressure to do writes should
    > increase, so that we tend, over time, to empty the buffer.
    >
    > A buffer is just that, not persistent storage.
    >
    > And in the case given, we were not seeing slow degradation, we saw
    > that the user ran into a wall (or inflection point in the response
    > time vs load graph), which was pretty sharp. We need to handle that
    > more gracefully.

    No doubt on the fact that we need to handle it gracefully,
    but as long as we don't have any answers to any of the
    tricky questions you're asking above it'll be kind of hard
    to come up with a patch ;))

    > Rik> This in turn means extra disk seeks, which can horribly interfere
    > Rik> with disk reads.
    >
    > True, but are we optomizing for reads or for writes here? Shouldn't
    > they really be equally weighted for priority? And wouldn't the
    > Elevator help handle this to a degree?

    We definately need to optimise for reads.

    Every time we do a read, we KNOW there's a process waiting
    on the data to come in from the disk.

    Most of the time we do writes, they'll be asynchronous
    delayed IO which is done in the background. The program
    which wrote the data has moved on to other things long
    since.

    > Some areas to think about, at least for me. And maybe it should be
    > read and write pressure, not rate?
    >
    > - low write rate, and a low read rate.
    > - Do seeks dominate our IO latency/throughput?

    Seeks always dominate IO latency ;)

    If you have a program which needs to get data from some file
    on disk, it is beneficial for that program if the disk head
    is near the data it wants.

    Moving the disk head all the way to the other side of the
    disk once a second will not slow the program down too much,
    but moving the disk head away 30 times a second "because
    there is little disk load" might just slow the program
    down by a factor of 2 ...

    Ie. if the head is in the same track or in the track next
    door, we only have rotational latency to count for (say 3ms),
    if we're on the other side of the disk we also have to count
    in seek time (say 7ms). Giving the program 30 * 7 = 210 ms
    extra IO wait time per second just isn't good ;)

    > - low write rate, high read rate.
    > - seems like we want to keep writing the buffers, but at a lower
    > rate.

    Not at a lower rate, just in larger blocks. Disk transfer
    rate is so rediculously high nowadays that seek time seems
    the only sensible thing to optimise for.

    regards,

    Rik
    --
    Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

    Virtual memory is like a game you can't win;
    However, without VM there's truly nothing to lose...

    http://www.surriel.com/
    http://www.conectiva.com/ http://distro.conectiva.com/

    -
    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 12:55    [W:3.429 / U:1.276 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site