Hi,
I have done some tests that appear to me at least to indicate that when
pdflush clears the dirty buffers and writes to disk, other processes will
block until the write completes.
Is this correct?
Here's what I've done. If you can explain it outside of a block, I'd like
to know. Thanks:
I notice that if I modify the pdflush behavior with these kernel parameters:
Code:
vm.dirty_writeback_centisecs=100
vm.dirty_expire_centisecs=100
...it appears to affect my dd writes negatively; that is, if I loop the dd
and run it over and over again, the time for dd to complete jumps on an
erratic basis.
Here's what I'm executing:
Code:
while true; do
echo -n ">>> New File >>>"; date +%r
/usr/bin/time -f "%E" /tmp/doit
done
*and /tmp/doit contains:*
dd if=/dev/zero of=/var/tmp/bigfile$i bs=1024 count=40000
oflag=nonblock 2>/dev/null
Then in another window, I am modifying sysctl parameters while the while
loop is running. First, the default settings:
Code:
sysctl -w vm.dirty_writeback_centisecs=500 ; sysctl -w
vm.dirty_expire_centisecs=3000
*then, after a bit, shorten the centisecs:*
sysctl -w vm.dirty_writeback_centisecs=100 ; sysctl -w
vm.dirty_expire_centisecs=100
*...observe times from the while loop. These should be more "choppy"*
The fact that the dd's more frequently take longer when the centisecs
parameter is shortened lead me to believe that my app is blocking when it
tries to write while the buffers are being flushed. The machine is otherwise
quiescent, and the size of the write (40 Meg) should not be enough to
trigger pdflush. It should happen every second, based on the sysctl
settings.
Note that dd is not doing direct i/o or synchronous i/o. If I explicitly set
those flags, it slows the write enormously. Note too that it doesn't matter
if I use the "nonblock" flag or not... i/o behavior is the same.
-Mike
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
