All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: ext4 development <linux-ext4@vger.kernel.org>, Jan Kara <jack@suse.cz>
Cc: Dave Wysochanski <dwysocha@redhat.com>
Subject: [PATCH RFC] jbd: don't wake kjournald unnecessarily
Date: Tue, 18 Dec 2012 11:03:57 -0600	[thread overview]
Message-ID: <50D0A1FD.7040203@redhat.com> (raw)

Commit d9b0193 jbd: fix fsync() tid wraparound bug
changed the logic for whether __log_start_commit() should wake up
kjournald.

After backporting this to RHEL6, I had a report of a performance regression
on a large benchmark, and it was narrowed down to the change above.

I did a little investigation of jbd behavior while running xfstest
013, which just does a large fsstress run, and found that we were
waking up kjournald more often than before; specifically,
in the case where

	target == j_commit_request == journal->j_running_transaction

It seems to me that the wakeup is not needed if we already have
the right target on the commit request, so I tested with the
additional condition added in the patch below; this brought
performance back up to prior levels.

I also tested it with tid_t defined to a u8, to get frequent wraps.
If I back out the wraparound patch, it will easily provoke
the original ASSERT that prompted the prior commit.  With
the commit in place and the patch below, I survived running
fsstress for 10 hours without problems even with a frequently-wrapping
tid_t.

A couple questions remain:

With a u8 tid_t, the "else" clause from commit d9b0193 fires
frequently; I really think the underlying problem is that tid_geq()
etc does not properly handle wraparounds - if, say, target is 255
and j_commit_request is 0, we don't know if j_commit_request
is 255 tids behind, or 1 tid ahead.  I have to think about that
some more, unless it's obvious to someone else.

FWIW, some people have indeed seen that else clause fire upstream,
both in the case where j_commit_request is > 2^31 and the 
target is 0.

https://bugzilla.kernel.org/show_bug.cgi?id=46031
http://forums.debian.net/viewtopic.php?f=5&t=80741

Anyway, I think this patch helps on the "don't send extra wakeups"
side of things.  Does anyone see a problem with it?

If it looks ok, I'll send the same for jbd2.

Thanks,
-Eric

=============
[PATCH] jbd: don't wake kjournald unnecessarily

Don't send an extra wakeup to kjournald in the case where we
already have the proper target in j_commit_request, i.e. that
commit has already been requested for commit.

commit d9b0193 "jbd: fix fsync() tid wraparound bug" changed
the logic leading to a wakeup, but it caused some extra wakeups
which were found to lead to a measurable performance regression.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
---
 
diff --git a/fs/jbd/journal.c b/fs/jbd/journal.c
index a286233..81cc7ea 100644
--- a/fs/jbd/journal.c
+++ b/fs/jbd/journal.c
@@ -446,7 +446,8 @@ int __log_start_commit(journal_t *journal, tid_t target)
 	 * currently running transaction (if it exists).  Otherwise,
 	 * the target tid must be an old one.
 	 */
-	if (journal->j_running_transaction &&
+	if (journal->j_commit_request != target &&
+	    journal->j_running_transaction &&
 	    journal->j_running_transaction->t_tid == target) {
 		/*
 		 * We want a new commit: OK, mark the request and wakeup the

             reply	other threads:[~2012-12-18 17:04 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-18 17:03 Eric Sandeen [this message]
2012-12-19  1:27 ` [PATCH RFC] jbd: don't wake kjournald unnecessarily Jan Kara
2012-12-19  2:05   ` Jan Kara
2012-12-19  3:08     ` Eric Sandeen
2012-12-19  8:13       ` Jan Kara
2012-12-19 15:37         ` Theodore Ts'o
2012-12-19 17:14           ` Jan Kara
2012-12-19 20:27             ` Theodore Ts'o
2012-12-19 21:19               ` Eric Sandeen
2012-12-21 17:01               ` Eric Sandeen
2012-12-21 17:46                 ` Theodore Ts'o
2013-01-08 19:19                   ` Eric Sandeen
2013-01-11 16:42                   ` Eric Sandeen
2013-01-11 19:03                     ` Jan Kara
2013-01-11 19:06                       ` Eric Sandeen
2012-12-19 15:46         ` Eric Sandeen
2012-12-19 17:11           ` Jan Kara
2012-12-19  2:36   ` Eric Sandeen
2012-12-19  2:59 ` [PATCH] jbd2: " Eric Sandeen
2012-12-19  8:09   ` Jan Kara

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=50D0A1FD.7040203@redhat.com \
    --to=sandeen@redhat.com \
    --cc=dwysocha@redhat.com \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.