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

    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.

    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?

    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?

    - low read rate, higher write rate (ie buffers filling faster than
    they are being written to disk)
    - Do we care as much about reads in this case?
    - If the write is just a small, high intensity burst, we don't want
    to go ape on writing out buffers to disk, but we do want to raise the
    rate we do so in the background, no?

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

    Just some thoughts...

    John
    John Stoffel - Senior Unix Systems Administrator - Lucent Technologies
    stoffel@lucent.com - http://www.lucent.com - 978-952-7548
    -
    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:0.022 / U:29.948 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site