Question about pdflush- does it block write()s?

[Yong Huang]

> From: "Mike Schwager" <fedora at schwager.com>
> Subject: Question about pdflush- does it block write()s?
> 
> 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

Mike, your research is very interesting. There may be one factor you can modify to see if the behavior is still the same, i.e. the number of disk spindles. If two I/O intensive processes write at the same time to the same hard disk, the elapsed time obviously gets longer.

Now suppose the observation is still valid regardless disk spindle count (i.e. pdflush freezes other I/O's). One thing I can think of is that pdflush probably initiates a system wide task freeze. I checked the code of pdflush.c (e.g. http://fxr.watson.org/fxr/source/mm/pdflush.c?v=linux-2.6). The try_to_freeze() call, generally explained at
http://www.mjmwired.net/kernel/Documentation/power/freezing-of-tasks.txt
is what I say here.

I'm not a kernel developer. A better place to ask this question may be LKML, or one dedicated to Linux kernel discussion short of code writing/patching itself (but I haven't found one yet). Thanks for your research. Your message definitely boosts the signal-to-noise ratio on this mailing list.

Yong Huang