linux-kernel - [RFC] writeback: abort writeback of the inode on wrap-around

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 2 Oct 2009 17:50:50 +0800
From:	Wu Fengguang <fengguang.wu@...el.com>
To:	Jan Kara <jack@...e.cz>
Cc:	Theodore Tso <tytso@....edu>,
	Christoph Hellwig <hch@...radead.org>,
	Dave Chinner <david@...morbit.com>,
	Chris Mason <chris.mason@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	"Li, Shaohua" <shaohua.li@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"richard@....demon.co.uk" <richard@....demon.co.uk>,
	"jens.axboe@...cle.com" <jens.axboe@...cle.com>,
	linux-fsdevel@...r.kernel.org, Steve French <sfrench@...ba.org>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Mark Fasheh <mfasheh@...e.com>,
	Joel Becker <joel.becker@...cle.com>,
	David Howells <dhowells@...hat.com>,
	Dave Kleikamp <shaggy@...ux.vnet.ibm.com>
Subject: [RFC] writeback: abort writeback of the inode on wrap-around

When past EOF, abort the writeback of the current inode, which will
instruct writeback_single_inode() to redirty_tail() it. 

This is the right behavior for
- sync writeback (is already so with range_whole)
  we have scanned the inode address space, and don't care any more newly
  dirtied pages. So shall update its i_dirtied_when and exclude it from
  the todo list.
- periodic writeback
  any more newly dirtied pages should be associated with a new expire
  time. This also prevents pointless IO for busy overwriters.
- background writeback (irrelevant)
  it generally don't care the dirty timestamp.

That should get rid of one inefficient IO pattern of .range_cyclic when
writeback_index wraps, in which the submitted pages may be consisted of
two distant ranges: submit [10000-10100], (wrap), submit [0-100].

The new .stop_on_wrap is a quick hack to show the basic idea. Ideal
would be to just convert the existing .range_cyclic to new behavior.
This should simplify a lot of code.

Since this involves many filesystems. I'd like to ask if any of them
in fact _desire_ the current .range_cyclic semantics to wrap?

Thanks,
Fengguang
---
 fs/fs-writeback.c         |    1 +
 include/linux/writeback.h |    1 +
 mm/page-writeback.c       |    4 +++-
 3 files changed, 5 insertions(+), 1 deletion(-)

--- linux.orig/fs/fs-writeback.c	2009-10-02 16:46:36.000000000 +0800
+++ linux/fs/fs-writeback.c	2009-10-02 17:01:27.000000000 +0800
@@ -810,6 +810,7 @@ static long wb_writeback(struct bdi_writ
 		.for_kupdate		= args->for_kupdate,
 		.for_background		= args->for_background,
 		.range_cyclic		= args->range_cyclic,
+		.stop_on_wrap		= 1,
 	};
 	unsigned long oldest_jif;
 	long wrote = 0;
--- linux.orig/include/linux/writeback.h	2009-10-02 16:46:36.000000000 +0800
+++ linux/include/linux/writeback.h	2009-10-02 16:57:13.000000000 +0800
@@ -57,6 +57,7 @@ struct writeback_control {
 	unsigned for_background:1;	/* A background writeback */
 	unsigned for_reclaim:1;		/* Invoked from the page allocator */
 	unsigned range_cyclic:1;	/* range_start is cyclic */
+	unsigned stop_on_wrap:1;	/* stop when write index is to wrap */
 	unsigned more_io:1;		/* more io to be dispatched */
 	/*
 	 * write_cache_pages() won't update wbc->nr_to_write and
--- linux.orig/mm/page-writeback.c	2009-10-02 16:46:36.000000000 +0800
+++ linux/mm/page-writeback.c	2009-10-02 16:57:13.000000000 +0800
@@ -913,7 +913,9 @@ continue_unlock:
 			break;
 		}
 	}
-	if (!cycled && !done) {
+	if (wbc->stop_on_wrap)
+		done_index = 0;
+	else if (!cycled && !done) {
 		/*
 		 * range_cyclic:
 		 * We hit the last page and there is more work to be done: wrap
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/