Message ID | 1310765198-10077-1-git-send-email-josef@redhat.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Fri, Jul 15, 2011 at 05:26:38PM -0400, Josef Bacik wrote: > Everybody else does this, we need to do it too. If we're syncing, we need to > tag the pages we're going to write for writeback so we don't end up writing the > same stuff over and over again if somebody is constantly redirtying our file. > This will keep us from having latencies with heavy sync workloads. Thanks, Maybe it's time to find a wait to merge the btrfs copy of write_cache_pages back into the main one? -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/15/2011 05:50 PM, Christoph Hellwig wrote: > On Fri, Jul 15, 2011 at 05:26:38PM -0400, Josef Bacik wrote: >> Everybody else does this, we need to do it too. If we're syncing, we need to >> tag the pages we're going to write for writeback so we don't end up writing the >> same stuff over and over again if somebody is constantly redirtying our file. >> This will keep us from having latencies with heavy sync workloads. Thanks, > > Maybe it's time to find a wait to merge the btrfs copy of write_cache_pages > back into the main one? I looked at it, but we need to be able to call a special helper to lock the page for our btree pages, and we can queue up a bio in order to add pages to it from delalloc which we will submit if we have to wait on a page to complete writeback. Maybe I can use the block plugging stuff instead of our bio thing so that if we have to wait it will get flushed automatically, then that just leaves our locking thing which I guess would be ok to pass down to write_cache_pages? Thanks, Josef -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index 9a43a96..9db9b0b 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -2516,6 +2516,7 @@ static int extent_write_cache_pages(struct extent_io_tree *tree, pgoff_t index; pgoff_t end; /* Inclusive */ int scanned = 0; + int tag; pagevec_init(&pvec, 0); if (wbc->range_cyclic) { @@ -2526,11 +2527,16 @@ static int extent_write_cache_pages(struct extent_io_tree *tree, end = wbc->range_end >> PAGE_CACHE_SHIFT; scanned = 1; } + if (wbc->sync_mode == WB_SYNC_ALL) + tag = PAGECACHE_TAG_TOWRITE; + else + tag = PAGECACHE_TAG_DIRTY; retry: + if (wbc->sync_mode == WB_SYNC_ALL) + tag_pages_for_writeback(mapping, index, end); while (!done && !nr_to_write_done && (index <= end) && - (nr_pages = pagevec_lookup_tag(&pvec, mapping, &index, - PAGECACHE_TAG_DIRTY, min(end - index, - (pgoff_t)PAGEVEC_SIZE-1) + 1))) { + (nr_pages = pagevec_lookup_tag(&pvec, mapping, &index, tag, + min(end - index, (pgoff_t)PAGEVEC_SIZE-1) + 1))) { unsigned i; scanned = 1;
Everybody else does this, we need to do it too. If we're syncing, we need to tag the pages we're going to write for writeback so we don't end up writing the same stuff over and over again if somebody is constantly redirtying our file. This will keep us from having latencies with heavy sync workloads. Thanks, Signed-off-by: Josef Bacik <josef@redhat.com> --- fs/btrfs/extent_io.c | 12 +++++++++--- 1 files changed, 9 insertions(+), 3 deletions(-)