Files
kernel_arpi/include/linux
Fengguang Wu 2e6883bdf4 writeback: introduce writeback_control.more_io to indicate more io
After making dirty a 100M file, the normal behavior is to start the writeback
for all data after 30s delays.  But sometimes the following happens instead:

	- after 30s:    ~4M
	- after 5s:     ~4M
	- after 5s:     all remaining 92M

Some analyze shows that the internal io dispatch queues goes like this:

		s_io            s_more_io
		-------------------------
	1)	100M,1K         0
	2)	1K              96M
	3)	0               96M

1) initial state with a 100M file and a 1K file
2) 4M written, nr_to_write <= 0, so write more
3) 1K written, nr_to_write > 0, no more writes(BUG)

nr_to_write > 0 in (3) fools the upper layer to think that data have all been
written out.  The big dirty file is actually still sitting in s_more_io.  We
cannot simply splice s_more_io back to s_io as soon as s_io becomes empty, and
let the loop in generic_sync_sb_inodes() continue: this may starve newly
expired inodes in s_dirty.  It is also not an option to draw inodes from both
s_more_io and s_dirty, an let the loop go on: this might lead to live locks,
and might also starve other superblocks in sync time(well kupdate may still
starve some superblocks, that's another bug).

We have to return when a full scan of s_io completes.  So nr_to_write > 0 does
not necessarily mean that "all data are written".  This patch introduces a
flag writeback_control.more_io to indicate this situation.  With it the big
dirty file no longer has to wait for the next kupdate invocation 5s later.

Cc: David Chinner <dgc@sgi.com>
Cc: Ken Chen <kenchen@google.com>
Signed-off-by: Fengguang Wu <wfg@mail.ustc.edu.cn>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-17 08:43:02 -07:00
..
2007-10-09 19:59:16 -07:00
2007-09-24 07:15:48 +02:00
2007-10-10 16:53:11 -07:00
2007-10-15 17:56:36 -07:00
2007-09-11 04:22:16 -07:00
2007-10-10 16:51:59 -07:00
2007-10-10 16:49:02 -07:00
2007-10-17 08:42:45 -07:00
2007-10-16 09:43:09 -07:00
2007-07-31 10:43:05 -05:00
2007-10-16 09:42:58 -07:00
2007-10-16 09:43:13 -07:00
2007-10-17 08:42:52 -07:00
2007-10-16 09:43:09 -07:00
2007-10-17 08:42:51 -07:00
2007-10-17 08:42:48 -07:00
2007-10-17 08:42:48 -07:00
2007-10-17 08:42:49 -07:00
2007-10-17 08:43:01 -07:00
2007-10-13 23:56:33 +02:00
2007-10-16 11:21:00 +02:00
2007-10-16 22:29:58 +02:00
2007-10-10 16:51:59 -07:00
2007-10-17 08:42:52 -07:00
2007-10-10 16:52:04 -07:00
2007-10-14 12:41:52 -07:00
2007-10-17 08:42:59 -07:00
2007-10-16 09:43:01 -07:00
2007-10-17 08:42:55 -07:00
2007-07-31 15:39:41 -07:00
2007-10-15 17:56:36 -07:00
2007-10-16 09:42:49 -07:00
2007-10-17 08:42:52 -07:00
2007-10-17 08:42:52 -07:00
2007-10-17 08:42:52 -07:00
2007-10-17 08:43:01 -07:00
2007-10-12 14:51:12 -07:00
2007-10-16 09:43:10 -07:00
2007-10-13 10:18:29 +02:00
2007-09-11 22:24:45 +01:00
2007-10-16 11:14:12 +02:00
2007-10-17 08:42:57 -07:00
2007-10-10 16:54:03 -07:00
2007-10-16 09:43:03 -07:00
2007-10-17 08:42:55 -07:00
2007-10-17 08:42:50 -07:00
2007-10-09 17:15:11 -04:00
2007-10-17 08:42:58 -07:00
2007-10-17 08:42:59 -07:00
2007-10-16 09:43:02 -07:00
2007-10-16 09:43:09 -07:00
2007-10-17 08:42:44 -07:00
2007-10-17 08:42:45 -07:00
2007-10-17 08:42:56 -07:00
2007-10-16 09:42:53 -07:00
2007-10-17 08:42:46 -07:00
2007-10-16 09:43:17 -07:00
2007-10-16 09:42:50 -07:00
2007-10-17 08:42:47 -07:00
2007-10-17 08:43:01 -07:00
2007-07-31 15:39:39 -07:00
2007-10-12 14:51:12 -07:00
2007-10-15 12:59:43 -07:00
2007-10-17 08:42:53 -07:00
2007-09-19 11:24:18 -07:00
2007-10-17 08:42:56 -07:00