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
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
firstname.lastname@example.org - 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 email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/