From: Andrew Morton <akpm@zip.com.au>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: lkml <linux-kernel@vger.kernel.org>
Subject: [patch 11/15] ext2: preread inode backing blocks
Date: Sun, 19 May 2002 12:43:36 -0700 [thread overview]
Message-ID: <3CE80068.997D5CD4@zip.com.au> (raw)
When ext2 creates a new inode, perform an asynchronous preread against
its backing block.
Without this patch, many-file writeout gets stalled by having to read
many individual inode table blocks in the middle of writeback.
It's worth about a 20% gain in writeback bandwidth for the many-file
writeback case.
ext3 already reads the inode's backing block in
ext3_new_inode->ext3_mark_inode_dirty, so no change is needed there.
A backport to 2.4 would make sense.
=====================================
--- 2.5.16/fs/ext2/ialloc.c~tuning-20-ext2-preread-inode Sun May 19 11:49:49 2002
+++ 2.5.16-akpm/fs/ext2/ialloc.c Sun May 19 11:49:49 2002
@@ -218,6 +218,44 @@ error_return:
}
/*
+ * We perform asynchronous prereading of the new inode's inode block when
+ * we create the inode, in the expectation that the inode will be written
+ * back soon. There are two reasons:
+ *
+ * - When creating a large number of files, the async prereads will be
+ * nicely merged into large reads
+ * - When writing out a large number of inodes, we don't need to keep on
+ * stalling the writes while we read the inode block.
+ *
+ * FIXME: ext2_get_group_desc() needs to be simplified.
+ */
+static void ext2_preread_inode(struct inode *inode)
+{
+ unsigned long block_group;
+ unsigned long offset;
+ unsigned long block;
+ struct buffer_head *bh;
+ struct ext2_group_desc * gdp;
+
+ block_group = (inode->i_ino - 1) / EXT2_INODES_PER_GROUP(inode->i_sb);
+ gdp = ext2_get_group_desc(inode->i_sb, block_group, &bh);
+ if (gdp == NULL)
+ return;
+
+ /*
+ * Figure out the offset within the block group inode table
+ */
+ offset = ((inode->i_ino - 1) % EXT2_INODES_PER_GROUP(inode->i_sb)) *
+ EXT2_INODE_SIZE(inode->i_sb);
+ block = le32_to_cpu(gdp->bg_inode_table) +
+ (offset >> EXT2_BLOCK_SIZE_BITS(inode->i_sb));
+ bh = sb_getblk(inode->i_sb, block);
+ if (!buffer_uptodate(bh) && !buffer_locked(bh))
+ ll_rw_block(READA, 1, &bh);
+ __brelse(bh);
+}
+
+/*
* There are two policies for allocating an inode. If the new inode is
* a directory, then a forward search is made for a block group with both
* free space and a low directory-to-inode ratio; if that fails, then of
@@ -417,6 +455,7 @@ repeat:
return ERR_PTR(-EDQUOT);
}
ext2_debug ("allocating inode %lu\n", inode->i_ino);
+ ext2_preread_inode(inode);
return inode;
fail2:
-
reply other threads:[~2002-05-19 19:41 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=3CE80068.997D5CD4@zip.com.au \
--to=akpm@zip.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.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 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.