FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Red Hat Linux

 
 
LinkBack Thread Tools
 
Old 09-26-2008, 08:09 PM
"Mike Schwager"
 
Default 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
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
 
Old 09-27-2008, 01:38 PM
"Mike Schwager"
 
Default 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
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
 
Old 09-27-2008, 10:45 PM
Yong Huang
 
Default Question about pdflush- does it block write()s?

> From: "Mike Schwager" <fedora@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





--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
 
Old 09-29-2008, 04:17 AM
Yong Huang
 
Default Question about pdflush- does it block write()s?

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@gmail.com> wrote:

> From: Andrey Meganov <a.meganov@gmail.com>
> Subject: Re: Question about pdflush- does it block write()s?
> To: yong321@yahoo.com, "General Red Hat Linux discussion list" <redhat-list@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@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@gmail.com>




--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
 

Thread Tools




All times are GMT. The time now is 07:04 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org