From: Christoph Hellwig <hch@lst.de>
To: axboe@kernel.dk
Cc: swhiteho@redhat.com, chris.mason@oracle.com,
linux-fsdevel@vger.kernel.org
Subject: [PATCH] block: BARRIER request should imply SYNC
Date: Thu, 17 Jun 2010 08:54:16 +0200 [thread overview]
Message-ID: <20100617065416.GA19903@lst.de> (raw)
A barrier request should by defintion have priority in get_request
and let the queue be unplugged immediately as it's blocking all forward
progress due to the queue draining.
Most filesystems already get this implicitly by the way how submit_bh
treats the buffer_ordered flag, and gfs2 sets it explicitly. But btrfs
and XFS are still forgetting to set the flag, as is blkdev_issue_flush
and some places in DM/MD.
For XFS on metadata heavy workloads this gives a consistent speedup
in the 2-3% range.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Index: linux-2.6/include/linux/fs.h
===================================================================
--- linux-2.6.orig/include/linux/fs.h 2010-06-17 08:37:05.238025121 +0200
+++ linux-2.6/include/linux/fs.h 2010-06-17 08:37:27.967253715 +0200
@@ -136,7 +136,7 @@ struct inodes_stat_t {
* SWRITE_SYNC
* SWRITE_SYNC_PLUG Like WRITE_SYNC/WRITE_SYNC_PLUG, but locks the buffer.
* See SWRITE.
- * WRITE_BARRIER Like WRITE, but tells the block layer that all
+ * WRITE_BARRIER Like WRITE_SYNC, but tells the block layer that all
* previously submitted writes must be safely on storage
* before this one is started. Also guarantees that when
* this write is complete, it itself is also safely on
@@ -159,7 +159,7 @@ struct inodes_stat_t {
#define SWRITE_SYNC_PLUG \
(SWRITE | (1 << BIO_RW_SYNCIO) | (1 << BIO_RW_NOIDLE))
#define SWRITE_SYNC (SWRITE_SYNC_PLUG | (1 << BIO_RW_UNPLUG))
-#define WRITE_BARRIER (WRITE | (1 << BIO_RW_BARRIER))
+#define WRITE_BARRIER (WRITE_SYNC | (1 << BIO_RW_BARRIER))
/*
* These aren't really reads or writes, they pass down information about
Index: linux-2.6/fs/gfs2/log.c
===================================================================
--- linux-2.6.orig/fs/gfs2/log.c 2010-06-17 08:42:18.020253855 +0200
+++ linux-2.6/fs/gfs2/log.c 2010-06-17 08:42:54.135032427 +0200
@@ -595,7 +595,7 @@ static void log_write_header(struct gfs2
if (test_bit(SDF_NOBARRIERS, &sdp->sd_flags))
goto skip_barrier;
get_bh(bh);
- submit_bh(WRITE_SYNC | (1 << BIO_RW_BARRIER) | (1 << BIO_RW_META), bh);
+ submit_bh(WRITE_BARRIER | (1 << BIO_RW_META), bh);
wait_on_buffer(bh);
if (buffer_eopnotsupp(bh)) {
clear_buffer_eopnotsupp(bh);
next reply other threads:[~2010-06-17 6:54 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-17 6:54 Christoph Hellwig [this message]
2010-06-17 7:34 ` [PATCH] block: BARRIER request should imply SYNC Jens Axboe
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=20100617065416.GA19903@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=chris.mason@oracle.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=swhiteho@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 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.