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@xxxxxxxxx> wrote: > From: Andrey Meganov <a.meganov@xxxxxxxxx> > Subject: Re: Question about pdflush- does it block write()s? > To: yong321@xxxxxxxxx, "General Red Hat Linux discussion list" <redhat-list@xxxxxxxxxx> > 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@xxxxxxxxxxxx> > > > 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@xxxxxxxxx> -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
