From: Suparna Bhattacharya <suparna@in.ibm.com>
To: akpm@osdl.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/5] Writeback page range hint
Date: Sun, 1 Aug 2004 13:17:51 +0530 [thread overview]
Message-ID: <20040801074751.GA7327@in.ibm.com> (raw)
In-Reply-To: <20040801074518.GA7310@in.ibm.com>
On Sun, Aug 01, 2004 at 01:15:18PM +0530, Suparna Bhattacharya wrote:
>
> The attached patches (generated against 2.6.8-rc2) enable concurrent
> O_SYNC writers to different parts of the same file by avoiding
> serialising on i_sem across the wait for IO completion.
>
> This is mostly your work, ported to the tagged radix tree VFS changes
> and a few fixes. I have been carrying these patches for sometime now;
> they can be the merged upstream. Please apply.
>
[1] writepages-range.patch
Regards
Suparna
--
Suparna Bhattacharya (suparna@in.ibm.com)
Linux Technology Center
IBM Software Lab, India
------------------------------------------------------
From: Andrew Morton <akpm@osdl.org>
Modify mpage_writepages to optionally only write back dirty pages within
a specified range in a file (as in the case of O_SYNC). Cheat a
little to avoid changes to prototypes of aops - just put the
<start, end> hint into the writeback_control struct instead.
If <start, end> are not set, then default to writing back all
the mapping's dirty pages.
Signed-off-by: Suparna Bhattacharya <suparna@in.ibm.com>
linux-2.6.8-rc2-suparna/fs/mpage.c | 27 +++++++++++++++++++---
linux-2.6.8-rc2-suparna/include/linux/writeback.h | 21 +++++++++++++----
2 files changed, 40 insertions(+), 8 deletions(-)
diff -puN fs/mpage.c~writepages-range fs/mpage.c
--- linux-2.6.8-rc2/fs/mpage.c~writepages-range 2004-08-01 12:30:15.000000000 +0530
+++ linux-2.6.8-rc2-suparna/fs/mpage.c 2004-08-01 12:30:15.000000000 +0530
@@ -622,7 +622,9 @@ mpage_writepages(struct address_space *m
struct pagevec pvec;
int nr_pages;
pgoff_t index;
+ pgoff_t end = -1; /* Inclusive */
int scanned = 0;
+ int is_range = 0;
if (wbc->nonblocking && bdi_write_congested(bdi)) {
wbc->encountered_congestion = 1;
@@ -640,9 +642,16 @@ mpage_writepages(struct address_space *m
index = 0; /* whole-file sweep */
scanned = 1;
}
+ if (wbc->start || wbc->end) {
+ index = wbc->start >> PAGE_CACHE_SHIFT;
+ end = wbc->end >> PAGE_CACHE_SHIFT;
+ is_range = 1;
+ scanned = 1;
+ }
retry:
while (!done && (nr_pages = pagevec_lookup_tag(&pvec, mapping, &index,
- PAGECACHE_TAG_DIRTY, PAGEVEC_SIZE))) {
+ PAGECACHE_TAG_DIRTY,
+ min(end - index, (pgoff_t)PAGEVEC_SIZE-1) + 1))) {
unsigned i;
scanned = 1;
@@ -659,10 +668,21 @@ retry:
lock_page(page);
+ if (unlikely(page->mapping != mapping)) {
+ unlock_page(page);
+ continue;
+ }
+
+ if (unlikely(is_range) && page->index > end) {
+ done = 1;
+ unlock_page(page);
+ continue;
+ }
+
if (wbc->sync_mode != WB_SYNC_NONE)
wait_on_page_writeback(page);
- if (page->mapping != mapping || PageWriteback(page) ||
+ if (PageWriteback(page) ||
!clear_page_dirty_for_io(page)) {
unlock_page(page);
continue;
@@ -701,7 +721,8 @@ retry:
index = 0;
goto retry;
}
- mapping->writeback_index = index;
+ if (!is_range)
+ mapping->writeback_index = index;
if (bio)
mpage_bio_submit(WRITE, bio);
return ret;
diff -puN include/linux/writeback.h~writepages-range include/linux/writeback.h
--- linux-2.6.8-rc2/include/linux/writeback.h~writepages-range 2004-08-01 12:30:15.000000000 +0530
+++ linux-2.6.8-rc2-suparna/include/linux/writeback.h 2004-08-01 12:30:15.000000000 +0530
@@ -29,7 +29,9 @@ enum writeback_sync_modes {
};
/*
- * A control structure which tells the writeback code what to do
+ * A control structure which tells the writeback code what to do. These are
+ * always on the stack, and hence need no locking. They are always initialised
+ * in a manner such that unspecified fields are set to zero.
*/
struct writeback_control {
struct backing_dev_info *bdi; /* If !NULL, only write back this
@@ -40,10 +42,19 @@ struct writeback_control {
long nr_to_write; /* Write this many pages, and decrement
this for each page written */
long pages_skipped; /* Pages which were not written */
- int nonblocking; /* Don't get stuck on request queues */
- int encountered_congestion; /* An output: a queue is full */
- int for_kupdate; /* A kupdate writeback */
- int for_reclaim; /* Invoked from the page allocator */
+
+ /*
+ * For a_ops->writepages(): is start or end are non-zero then this is
+ * a hint that the filesystem need only write out the pages inside that
+ * byterange. The byte at `end' is included in the writeout request.
+ */
+ loff_t start;
+ loff_t end;
+
+ int nonblocking:1; /* Don't get stuck on request queues */
+ int encountered_congestion:1; /* An output: a queue is full */
+ int for_kupdate:1; /* A kupdate writeback */
+ int for_reclaim:1; /* Invoked from the page allocator */
};
/*
_
next prev parent reply other threads:[~2004-08-01 7:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-01 7:45 [PATCH 0/5] Concurrent O_SYNC write speedups using radix-tree walks Suparna Bhattacharya
2004-08-01 7:47 ` Suparna Bhattacharya [this message]
2004-08-01 7:49 ` [PATCH 2/5] Fix writeback page range to use exact limits Suparna Bhattacharya
2004-08-01 7:50 ` [PATCH 3/5] mpage writepages range limit fix Suparna Bhattacharya
2004-08-01 7:52 ` [PATCH 4/5] filemap_fdatawrite range interface Suparna Bhattacharya
2004-08-01 7:53 ` [PATCH 5/5] Concurrent O_SYNC write support Suparna Bhattacharya
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=20040801074751.GA7327@in.ibm.com \
--to=suparna@in.ibm.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@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.