cluster-devel.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Andrew Price <anprice@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH 2/2] fsck.gfs2: Improve read ahead in pass1_process_bitmap
Date: Fri, 11 Sep 2015 12:35:04 +0100	[thread overview]
Message-ID: <1441971304-31556-2-git-send-email-anprice@redhat.com> (raw)
In-Reply-To: <1441971304-31556-1-git-send-email-anprice@redhat.com>

The read ahead strategy in this function was pretty naive, it just read
in all of the inode blocks, in block-sized reads, before doing any
processing. In my tests with a full filesystem, removing this read ahead
actually sped up the tests, presumably due to issuing a large number of
small I/Os and not keeping them cached. Moving the read ahead into the
processing loop and reading ahead by larger chunks after certain periods
gave improved performance. After some experimentation, I found the best
performance was given by reading ahead 100 blocks after every 50 inodes
processed. Timings were:

    Master        Without R.A.  With this patch
    51:03.41      48:07.40      47:13.66
    50:56.45      48:07.42      47:01.04
    51:02.25      48:00.06      47:05.72

I would expect the performance gain to be larger on filesystems with a
higher density of inode blocks.

Signed-off-by: Andrew Price <anprice@redhat.com>
---
 gfs2/fsck/pass1.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/gfs2/fsck/pass1.c b/gfs2/fsck/pass1.c
index c0f2f1e..653be59 100644
--- a/gfs2/fsck/pass1.c
+++ b/gfs2/fsck/pass1.c
@@ -1532,17 +1532,22 @@ static int pass1_process_bitmap(struct gfs2_sbd *sdp, struct rgrp_tree *rgd, uin
 	uint64_t block;
 	struct gfs2_inode *ip;
 	uint8_t q;
+	/* Readahead numbers arrived at by experiment */
+	unsigned rawin = 50;
+	unsigned ralen = 100 * sdp->bsize;
+	unsigned r = 0;
 
-	/* Issue read-ahead for all dinodes in this bitmap */
-	for (i = 0; i < n; i++)
-		posix_fadvise(sdp->device_fd, ibuf[i] * sdp->bsize, sdp->bsize,
-			      POSIX_FADV_WILLNEED);
 	for (i = 0; i < n; i++) {
 		int is_inode;
 		uint32_t check_magic;
 
 		block = ibuf[i];
 
+		if (r++ == rawin) {
+			posix_fadvise(sdp->device_fd, block * sdp->bsize, ralen, POSIX_FADV_WILLNEED);
+			r = 0;
+		}
+
 		/* skip gfs1 rindex indirect blocks */
 		if (sdp->gfs1 && blockfind(&gfs1_rindex_blks, block)) {
 			log_debug(_("Skipping rindex indir block "
-- 
2.4.3



      reply	other threads:[~2015-09-11 11:35 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-11 11:35 [Cluster-devel] [PATCH 1/2] fsck.gfs2: Really be quiet in quiet mode Andrew Price
2015-09-11 11:35 ` Andrew Price [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=1441971304-31556-2-git-send-email-anprice@redhat.com \
    --to=anprice@redhat.com \
    /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).