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

[Yong Huang]

Ignore my comment about possible system wide freeze. I was misreading the code. try_to_freeze() appears in all kernel threads, and attempts to freeze the *current process itself* if there's a request to do so.

Yong Huang

--- On Sun, 9/28/08, Andrey Meganov <a.meganov at gmail.com> wrote:

> From: Andrey Meganov <a.meganov at gmail.com>
> Subject: Re: Question about pdflush- does it block write()s?
> To: yong321 at yahoo.com, "General Red Hat Linux discussion list" <redhat-list at redhat.com>
> Date: Sunday, September 28, 2008, 9:24 AM
> Sorry, pals your research shows nothing. =)
> 
> Ext3 has block group structure, which causs files to be
> spread across
> block groups, which are located at different tracks (and
> cylinders) of
> the disk. Those different tracks naturally (because the
> disc is round)
> have totally different linear write speeds. Which can
> differ by the
> factor of 1,5 - 2. That's why even if you turn off
> swap, you will have
> random times. =)
> 
> Don't forget the seek time, which also plays it's
> role. Even if pdflush
> kicks in, it just anothe queue in the CFQ I/O scheduler, so
> it
> definitely does not block the processes. 
> 
> BR,
> Andrey
> Am Samstag, den 27.09.2008, 15:45 -0700 schrieb 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
> 
> -- 
> Andrey Meganov <a.meganov at gmail.com>