[lkml]   [2001]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
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

Just some thoughts...

John Stoffel - Senior Unix Systems Administrator - Lucent Technologies - - 978-952-7548
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 12:55    [W:0.295 / U:0.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site