From: Josef Bacik <jbacik@redhat.com>
To: Theodore Tso <tytso@mit.edu>
Cc: Andreas Dilger <adilger@sun.com>, Josef Bacik <jbacik@redhat.com>,
linux-ext4@vger.kernel.org
Subject: Re: [PATCH] imporve jbd2 fsync batching
Date: Wed, 26 Nov 2008 08:18:06 -0500 [thread overview]
Message-ID: <20081126131806.GE587@unused.rdu.redhat.com> (raw)
In-Reply-To: <20081126051057.GE1410@mit.edu>
On Wed, Nov 26, 2008 at 12:10:57AM -0500, Theodore Tso wrote:
> On Tue, Nov 25, 2008 at 03:41:15PM -0700, Andreas Dilger wrote:
> > > Stupid question... if the goal is to not have the average commit time
> > > not react too strongly to sudden and vast changes to the commit time,
> > > would it be better to do this instead:
> > >
> > > > + journal->j_average_commit_time = (commit_time +
> > > > + journal->j_average_commit_time*3) / 4;
> >
> > Actually, yes. That is my fault, I'd suggested the original change to
> > Josef.
>
> BTW, I've added a patch to display the average commit time it does
> vary wildly, especially on a laptop hard drive. While the system is
> idle, and the occasional commits need to wait for the hard drive to
> wake up, leads to a average commit time of around 80-140ms. If the
> disk is just getting lightly tickled, such that it never has a chance
> to go to sleep, the average commit time can drop down to around
> 20-25ms. If the hard drive is really busy, then the average commit
> time can go up to 40-50ms.
>
> Increasing the weight as described below will slow down the move to
> these long-term averages, but at least for laptop or Green Star drives
> with power savings enabled, the average commit time does seem to vary
> in some non-inintuitive ways. Of course, if we are capping the max
> transaction time at 15ms, most of this will never be visible, but it
> would probably be interesting to test out this patch on a fast SSD or
> an expensive enterprise array to see whether are similar surprising
> variations in the average commit time.
>
I was printing out the commit time when I was testing this and with high end
storage the commit time didn't vary all that much. With my SATA drive on a
normal running box it didn't vary all that much either, it would drop down to
like 1ms because of syslog, but other than that it would ramp up when there was
load and it would slowly come back down as the load went away. Also do you
want a new patch with that fix, or will you just fix it up? Thanks,
Josef
prev parent reply other threads:[~2008-11-26 13:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-04 16:10 [PATCH] imporve jbd2 fsync batching Josef Bacik
2008-11-04 20:52 ` Theodore Tso
2008-11-04 22:15 ` Leroy van Logchem
2008-11-05 23:10 ` Andreas Dilger
2008-11-06 0:27 ` Theodore Tso
2008-11-06 12:45 ` Ric Wheeler
2008-11-25 10:22 ` [PATCH] ext4: add fsync batch tuning knobs Theodore Tso
2008-12-02 14:45 ` Aneesh Kumar K.V
2008-11-06 14:35 ` [PATCH] imporve jbd2 fsync batching Josef Bacik
2008-11-25 10:23 ` Theodore Tso
2008-11-25 22:41 ` Andreas Dilger
2008-11-26 5:10 ` Theodore Tso
2008-11-26 13:18 ` Josef Bacik [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081126131806.GE587@unused.rdu.redhat.com \
--to=jbacik@redhat.com \
--cc=adilger@sun.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).