From: Wu Fengguang <fengguang.wu@intel.com> To: Peter Zijlstra <peterz@infradead.org> Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>, Andrew Morton <akpm@linux-foundation.org>, Jan Kara <jack@suse.cz>, Christoph Hellwig <hch@lst.de>, Dave Chinner <david@fromorbit.com>, Greg Thelen <gthelen@google.com>, Minchan Kim <minchan.kim@gmail.com>, Vivek Goyal <vgoyal@redhat.com>, Andrea Righi <arighi@develer.com>, linux-mm <linux-mm@kvack.org>, LKML <linux-kernel@vger.kernel.org> Subject: Re: [PATCH 2/5] writeback: dirty position control Date: Tue, 23 Aug 2011 11:40:42 +0800 [thread overview] Message-ID: <20110823034042.GC7332@localhost> (raw) In-Reply-To: <1314027488.24275.74.camel@twins> On Mon, Aug 22, 2011 at 11:38:07PM +0800, Peter Zijlstra wrote: > On Fri, 2011-08-12 at 22:20 +0800, Wu Fengguang wrote: > > On Fri, Aug 12, 2011 at 09:04:19PM +0800, Peter Zijlstra wrote: > > > On Tue, 2011-08-09 at 19:20 +0200, Peter Zijlstra wrote: > > > > To start with, > > > > write_bw > > ref_bw = task_ratelimit_in_past_200ms * -------- > > dirty_bw > > > > where > > task_ratelimit_in_past_200ms ~= dirty_ratelimit * pos_ratio > > > > > > Now all of the above would seem to suggest: > > > > > > > > dirty_ratelimit := ref_bw > > > > Right, ideally ref_bw is the balanced dirty ratelimit. I actually > > started with exactly the above equation when I got choked by pure > > pos_bw based feedback control (as mentioned in the reply to Jan's > > email) and introduced the ref_bw estimation as the way out. > > > > But there are some imperfections in ref_bw, too. Which makes it not > > suitable for direct use: > > > > 1) large fluctuations > > OK, understood. > > > 2) due to truncates and fs redirties, the (write_bw <=> dirty_bw) > > becomes unbalanced match, which leads to large systematical errors > > in ref_bw. The truncates, due to its possibly bumpy nature, can hardly > > be compensated smoothly. > > OK. > > > 3) since we ultimately want to > > > > - keep the dirty pages around the setpoint as long time as possible > > - keep the fluctuations of task ratelimit as small as possible > > Fair enough ;-) > > > the update policy used for (2) also serves the above goals nicely: > > if for some reason the dirty pages are high (pos_bw < dirty_ratelimit), > > and dirty_ratelimit is low (dirty_ratelimit < ref_bw), there is no > > point to bring up dirty_ratelimit in a hurry and to hurt both the > > above two goals. > > Right, so still I feel somewhat befuddled, so we have: > > dirty_ratelimit - rate at which we throttle dirtiers as > estimated upto 200ms ago. Note that bdi->dirty_ratelimit is supposed to be the balanced ratelimit, ie. (write_bw / N), regardless whether dirty pages meets the setpoint. In _concept_, the bdi balanced ratelimit is updated _independent_ of the position control embodied in the task ratelimit calculation. A lot of confusions seem to come from the seemingly inter-twisted rate and position controls, however in my mind, there are two levels of relationship: 1) work fundamentally independent of each other, each tries to fulfill one single target (either balanced rate or balanced position) 2) _based_ on (1), completely optional, try to constraint the rate update to get more stable ->dirty_ratelimit and more balanced dirty position Note that (2) is not a must even if there are systematic errors in balanced_rate calculation. For example, the v8 patchset only does (1) and hence do simple bdi->dirty_ratelimit = balanced_rate; And it can still balance at some point (though not exactly around the setpoint): http://www.kernel.org/pub/linux/kernel/people/wfg/writeback/dirty-throttling-v8/3G-bs=1M/ext4-1dd-1M-8p-2942M-20:10-3.0.0-next-20110802+-2011-08-08.19:47/balance_dirty_pages-pages.png Even if ext4 has mis-matched (dirty_rate:write_bw ~= 3:2) hence introduced systematic errors in balanced_rate: http://www.kernel.org/pub/linux/kernel/people/wfg/writeback/dirty-throttling-v8/3G-bs=1M/ext4-1dd-1M-8p-2942M-20:10-3.0.0-next-20110802+-2011-08-08.19:47/global_dirtied_written.png > pos_ratio - ratio adjusting the dirty_ratelimit > for variance in dirty pages around its target So pos_ratio is - is a _limiting_ factor rather than an _adjusting_ factor for updating ->dirty_ratelimit (when do (2)) - not a factor at all for updating balanced_rate (whether or not we do (2)) well, in this concept: the balanced_rate formula inherently does not derive the balanced_rate_(i+1) from balanced_rate_i. Rather it's based on the ratelimit executed for the past 200ms: balanced_rate_(i+1) = task_ratelimit_200ms * bw_ratio and task_ratelimit_200ms happen to can be estimated from task_ratelimit_200ms ~= balanced_rate_i * pos_ratio There is fundamentally no dependency between balanced_rate_(i+1) and balanced_rate_i/task_ratelimit_200ms: the balanced_rate estimation only asks for _whatever_ CONSTANT task ratelimit to be executed for 200ms, then it get the balanced rate from the dirty_rate feedback. We may alternatively record every task_ratelimit executed in the past 200ms and average them all to get task_ratelimit_200ms. In this way we take the "superfluous" pos_ratio out of sight :) > bw_ratio - ratio adjusting the dirty_ratelimit > for variance in input/output bandwidth > > and we need to basically do: > > dirty_ratelimit *= pos_ratio * bw_ratio So there is even no such recursing at all: balanced_rate *= bw_ratio Each balanced_rate is estimated from the start, based on each 200ms period. > to update the dirty_ratelimit to reflect the current state. However per > 1) and 2) bw_ratio is crappy and hard to fix. > > So you propose to update dirty_ratelimit only if both pos_ratio and > bw_ratio point in the same direction, however that would result in: > > if (pos_ratio < UNIT && bw_ratio < UNIT || > pos_ratio > UNIT && bw_ratio > UNIT) { > dirty_ratelimit = (dirty_ratelimit * pos_ratio) / UNIT; > dirty_ratelimit = (dirty_ratelimit * bw_ratio) / UNIT; > } We start by doing this for (1): dirty_ratelimit = balanced_rate and then try to refine it for (1)+(2): dirty_ratelimit => balanced_rate, but limit the progress by pos_ratio > > > > However for that you use: > > > > > > > > if (pos_bw < dirty_ratelimit && ref_bw < dirty_ratelimit) > > > > dirty_ratelimit = max(ref_bw, pos_bw); > > > > > > > > if (pos_bw > dirty_ratelimit && ref_bw > dirty_ratelimit) > > > > dirty_ratelimit = min(ref_bw, pos_bw); > > > > The above are merely constraints to the dirty_ratelimit update. > > It serves to > > > > 1) stop adjusting the rate when it's against the position control > > target (the adjusted rate will slow down the progress of dirty > > pages going back to setpoint). > > Not strictly speaking, suppose pos_ratio = 0.5 and bw_ratio = 1.1, then > they point in different directions however: > > 0.5 < 1 && 0.5 * 1.1 < 1 > > so your code will in fact update the dirty_ratelimit, even though the > two factors point in opposite directions. It does not work that way since pos_ratio does not take part in the multiplication. However I admit that the tests (pos_bw < dirty_ratelimit && ref_bw < dirty_ratelimit) (pos_bw > dirty_ratelimit && ref_bw > dirty_ratelimit) don't aim to avoid all unnecessary updates, and it may even stop some rightful updates. It's not possible at all to act perfect. It's merely a rule that sounds "reasonable" in theory and works reasonably good in practice :) I'd be happy to try more if there are better ones. > > 2) limit the step size. pos_bw is changing values step by step, > > leaving a consistent trace comparing to the randomly jumping > > ref_bw. pos_bw also has smaller errors in stable state and normally > > have larger errors when there are big errors in rate. So it's a > > pretty good limiting factor for the step size of dirty_ratelimit. > > OK, so that's the min/max stuff, however it only works because you use > pos_bw and ref_bw instead of the fully separated factors. Yes, the min/max stuff is for limiting the step size. The "limiting" intention can be made more clear if written as delta = balanced_rate - base_rate; if (delta > pos_rate - base_rate) delta = pos_rate - base_rate; delta /= 8; > > Hope the above elaboration helps :) > > A little.. And now? ;) Thanks, Fengguang
WARNING: multiple messages have this Message-ID (diff)
From: Wu Fengguang <fengguang.wu@intel.com> To: Peter Zijlstra <peterz@infradead.org> Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>, Andrew Morton <akpm@linux-foundation.org>, Jan Kara <jack@suse.cz>, Christoph Hellwig <hch@lst.de>, Dave Chinner <david@fromorbit.com>, Greg Thelen <gthelen@google.com>, Minchan Kim <minchan.kim@gmail.com>, Vivek Goyal <vgoyal@redhat.com>, Andrea Righi <arighi@develer.com>, linux-mm <linux-mm@kvack.org>, LKML <linux-kernel@vger.kernel.org> Subject: Re: [PATCH 2/5] writeback: dirty position control Date: Tue, 23 Aug 2011 11:40:42 +0800 [thread overview] Message-ID: <20110823034042.GC7332@localhost> (raw) In-Reply-To: <1314027488.24275.74.camel@twins> On Mon, Aug 22, 2011 at 11:38:07PM +0800, Peter Zijlstra wrote: > On Fri, 2011-08-12 at 22:20 +0800, Wu Fengguang wrote: > > On Fri, Aug 12, 2011 at 09:04:19PM +0800, Peter Zijlstra wrote: > > > On Tue, 2011-08-09 at 19:20 +0200, Peter Zijlstra wrote: > > > > To start with, > > > > write_bw > > ref_bw = task_ratelimit_in_past_200ms * -------- > > dirty_bw > > > > where > > task_ratelimit_in_past_200ms ~= dirty_ratelimit * pos_ratio > > > > > > Now all of the above would seem to suggest: > > > > > > > > dirty_ratelimit := ref_bw > > > > Right, ideally ref_bw is the balanced dirty ratelimit. I actually > > started with exactly the above equation when I got choked by pure > > pos_bw based feedback control (as mentioned in the reply to Jan's > > email) and introduced the ref_bw estimation as the way out. > > > > But there are some imperfections in ref_bw, too. Which makes it not > > suitable for direct use: > > > > 1) large fluctuations > > OK, understood. > > > 2) due to truncates and fs redirties, the (write_bw <=> dirty_bw) > > becomes unbalanced match, which leads to large systematical errors > > in ref_bw. The truncates, due to its possibly bumpy nature, can hardly > > be compensated smoothly. > > OK. > > > 3) since we ultimately want to > > > > - keep the dirty pages around the setpoint as long time as possible > > - keep the fluctuations of task ratelimit as small as possible > > Fair enough ;-) > > > the update policy used for (2) also serves the above goals nicely: > > if for some reason the dirty pages are high (pos_bw < dirty_ratelimit), > > and dirty_ratelimit is low (dirty_ratelimit < ref_bw), there is no > > point to bring up dirty_ratelimit in a hurry and to hurt both the > > above two goals. > > Right, so still I feel somewhat befuddled, so we have: > > dirty_ratelimit - rate at which we throttle dirtiers as > estimated upto 200ms ago. Note that bdi->dirty_ratelimit is supposed to be the balanced ratelimit, ie. (write_bw / N), regardless whether dirty pages meets the setpoint. In _concept_, the bdi balanced ratelimit is updated _independent_ of the position control embodied in the task ratelimit calculation. A lot of confusions seem to come from the seemingly inter-twisted rate and position controls, however in my mind, there are two levels of relationship: 1) work fundamentally independent of each other, each tries to fulfill one single target (either balanced rate or balanced position) 2) _based_ on (1), completely optional, try to constraint the rate update to get more stable ->dirty_ratelimit and more balanced dirty position Note that (2) is not a must even if there are systematic errors in balanced_rate calculation. For example, the v8 patchset only does (1) and hence do simple bdi->dirty_ratelimit = balanced_rate; And it can still balance at some point (though not exactly around the setpoint): http://www.kernel.org/pub/linux/kernel/people/wfg/writeback/dirty-throttling-v8/3G-bs=1M/ext4-1dd-1M-8p-2942M-20:10-3.0.0-next-20110802+-2011-08-08.19:47/balance_dirty_pages-pages.png Even if ext4 has mis-matched (dirty_rate:write_bw ~= 3:2) hence introduced systematic errors in balanced_rate: http://www.kernel.org/pub/linux/kernel/people/wfg/writeback/dirty-throttling-v8/3G-bs=1M/ext4-1dd-1M-8p-2942M-20:10-3.0.0-next-20110802+-2011-08-08.19:47/global_dirtied_written.png > pos_ratio - ratio adjusting the dirty_ratelimit > for variance in dirty pages around its target So pos_ratio is - is a _limiting_ factor rather than an _adjusting_ factor for updating ->dirty_ratelimit (when do (2)) - not a factor at all for updating balanced_rate (whether or not we do (2)) well, in this concept: the balanced_rate formula inherently does not derive the balanced_rate_(i+1) from balanced_rate_i. Rather it's based on the ratelimit executed for the past 200ms: balanced_rate_(i+1) = task_ratelimit_200ms * bw_ratio and task_ratelimit_200ms happen to can be estimated from task_ratelimit_200ms ~= balanced_rate_i * pos_ratio There is fundamentally no dependency between balanced_rate_(i+1) and balanced_rate_i/task_ratelimit_200ms: the balanced_rate estimation only asks for _whatever_ CONSTANT task ratelimit to be executed for 200ms, then it get the balanced rate from the dirty_rate feedback. We may alternatively record every task_ratelimit executed in the past 200ms and average them all to get task_ratelimit_200ms. In this way we take the "superfluous" pos_ratio out of sight :) > bw_ratio - ratio adjusting the dirty_ratelimit > for variance in input/output bandwidth > > and we need to basically do: > > dirty_ratelimit *= pos_ratio * bw_ratio So there is even no such recursing at all: balanced_rate *= bw_ratio Each balanced_rate is estimated from the start, based on each 200ms period. > to update the dirty_ratelimit to reflect the current state. However per > 1) and 2) bw_ratio is crappy and hard to fix. > > So you propose to update dirty_ratelimit only if both pos_ratio and > bw_ratio point in the same direction, however that would result in: > > if (pos_ratio < UNIT && bw_ratio < UNIT || > pos_ratio > UNIT && bw_ratio > UNIT) { > dirty_ratelimit = (dirty_ratelimit * pos_ratio) / UNIT; > dirty_ratelimit = (dirty_ratelimit * bw_ratio) / UNIT; > } We start by doing this for (1): dirty_ratelimit = balanced_rate and then try to refine it for (1)+(2): dirty_ratelimit => balanced_rate, but limit the progress by pos_ratio > > > > However for that you use: > > > > > > > > if (pos_bw < dirty_ratelimit && ref_bw < dirty_ratelimit) > > > > dirty_ratelimit = max(ref_bw, pos_bw); > > > > > > > > if (pos_bw > dirty_ratelimit && ref_bw > dirty_ratelimit) > > > > dirty_ratelimit = min(ref_bw, pos_bw); > > > > The above are merely constraints to the dirty_ratelimit update. > > It serves to > > > > 1) stop adjusting the rate when it's against the position control > > target (the adjusted rate will slow down the progress of dirty > > pages going back to setpoint). > > Not strictly speaking, suppose pos_ratio = 0.5 and bw_ratio = 1.1, then > they point in different directions however: > > 0.5 < 1 && 0.5 * 1.1 < 1 > > so your code will in fact update the dirty_ratelimit, even though the > two factors point in opposite directions. It does not work that way since pos_ratio does not take part in the multiplication. However I admit that the tests (pos_bw < dirty_ratelimit && ref_bw < dirty_ratelimit) (pos_bw > dirty_ratelimit && ref_bw > dirty_ratelimit) don't aim to avoid all unnecessary updates, and it may even stop some rightful updates. It's not possible at all to act perfect. It's merely a rule that sounds "reasonable" in theory and works reasonably good in practice :) I'd be happy to try more if there are better ones. > > 2) limit the step size. pos_bw is changing values step by step, > > leaving a consistent trace comparing to the randomly jumping > > ref_bw. pos_bw also has smaller errors in stable state and normally > > have larger errors when there are big errors in rate. So it's a > > pretty good limiting factor for the step size of dirty_ratelimit. > > OK, so that's the min/max stuff, however it only works because you use > pos_bw and ref_bw instead of the fully separated factors. Yes, the min/max stuff is for limiting the step size. The "limiting" intention can be made more clear if written as delta = balanced_rate - base_rate; if (delta > pos_rate - base_rate) delta = pos_rate - base_rate; delta /= 8; > > Hope the above elaboration helps :) > > A little.. And now? ;) Thanks, Fengguang -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-08-23 3:40 UTC|newest] Thread overview: 305+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-08-06 8:44 [PATCH 0/5] IO-less dirty throttling v8 Wu Fengguang 2011-08-06 8:44 ` Wu Fengguang 2011-08-06 8:44 ` Wu Fengguang 2011-08-06 8:44 ` [PATCH 1/5] writeback: account per-bdi accumulated dirtied pages Wu Fengguang 2011-08-06 8:44 ` Wu Fengguang 2011-08-06 8:44 ` Wu Fengguang 2011-08-06 8:44 ` [PATCH 2/5] writeback: dirty position control Wu Fengguang 2011-08-06 8:44 ` Wu Fengguang 2011-08-06 8:44 ` Wu Fengguang 2011-08-08 13:46 ` Peter Zijlstra 2011-08-08 13:46 ` Peter Zijlstra 2011-08-08 13:46 ` Peter Zijlstra 2011-08-08 14:11 ` Wu Fengguang 2011-08-08 14:11 ` Wu Fengguang 2011-08-08 14:31 ` Peter Zijlstra 2011-08-08 14:31 ` Peter Zijlstra 2011-08-08 14:31 ` Peter Zijlstra 2011-08-08 22:47 ` Wu Fengguang 2011-08-08 22:47 ` Wu Fengguang 2011-08-09 9:31 ` Peter Zijlstra 2011-08-09 9:31 ` Peter Zijlstra 2011-08-09 9:31 ` Peter Zijlstra 2011-08-10 12:28 ` Wu Fengguang 2011-08-10 12:28 ` Wu Fengguang 2011-08-08 14:41 ` Peter Zijlstra 2011-08-08 14:41 ` Peter Zijlstra 2011-08-08 14:41 ` Peter Zijlstra 2011-08-08 23:05 ` Wu Fengguang 2011-08-08 23:05 ` Wu Fengguang 2011-08-09 10:32 ` Peter Zijlstra 2011-08-09 10:32 ` Peter Zijlstra 2011-08-09 10:32 ` Peter Zijlstra 2011-08-09 17:20 ` Peter Zijlstra 2011-08-09 17:20 ` Peter Zijlstra 2011-08-09 17:20 ` Peter Zijlstra 2011-08-10 22:34 ` Jan Kara 2011-08-10 22:34 ` Jan Kara 2011-08-11 2:29 ` Wu Fengguang 2011-08-11 2:29 ` Wu Fengguang 2011-08-11 11:14 ` Jan Kara 2011-08-11 11:14 ` Jan Kara 2011-08-16 8:35 ` Wu Fengguang 2011-08-16 8:35 ` Wu Fengguang 2011-08-12 13:19 ` Wu Fengguang 2011-08-12 13:19 ` Wu Fengguang 2011-08-10 21:40 ` Vivek Goyal 2011-08-10 21:40 ` Vivek Goyal 2011-08-16 8:55 ` Wu Fengguang 2011-08-16 8:55 ` Wu Fengguang 2011-08-11 22:56 ` Peter Zijlstra 2011-08-11 22:56 ` Peter Zijlstra 2011-08-11 22:56 ` Peter Zijlstra 2011-08-12 2:43 ` Wu Fengguang 2011-08-12 2:43 ` Wu Fengguang 2011-08-12 3:18 ` Wu Fengguang 2011-08-12 5:45 ` Wu Fengguang 2011-08-12 5:45 ` Wu Fengguang 2011-08-12 9:45 ` Peter Zijlstra 2011-08-12 9:45 ` Peter Zijlstra 2011-08-12 9:45 ` Peter Zijlstra 2011-08-12 11:07 ` Wu Fengguang 2011-08-12 11:07 ` Wu Fengguang 2011-08-12 12:17 ` Peter Zijlstra 2011-08-12 12:17 ` Peter Zijlstra 2011-08-12 12:17 ` Peter Zijlstra 2011-08-12 9:47 ` Peter Zijlstra 2011-08-12 9:47 ` Peter Zijlstra 2011-08-12 9:47 ` Peter Zijlstra 2011-08-12 11:11 ` Wu Fengguang 2011-08-12 11:11 ` Wu Fengguang 2011-08-12 12:54 ` Peter Zijlstra 2011-08-12 12:54 ` Peter Zijlstra 2011-08-12 12:54 ` Peter Zijlstra 2011-08-12 12:59 ` Wu Fengguang 2011-08-12 12:59 ` Wu Fengguang 2011-08-12 13:08 ` Peter Zijlstra 2011-08-12 13:08 ` Peter Zijlstra 2011-08-12 13:08 ` Peter Zijlstra 2011-08-12 13:04 ` Peter Zijlstra 2011-08-12 13:04 ` Peter Zijlstra 2011-08-12 13:04 ` Peter Zijlstra 2011-08-12 14:20 ` Wu Fengguang 2011-08-12 14:20 ` Wu Fengguang 2011-08-22 15:38 ` Peter Zijlstra 2011-08-22 15:38 ` Peter Zijlstra 2011-08-22 15:38 ` Peter Zijlstra 2011-08-23 3:40 ` Wu Fengguang [this message] 2011-08-23 3:40 ` Wu Fengguang 2011-08-23 10:01 ` Peter Zijlstra 2011-08-23 10:01 ` Peter Zijlstra 2011-08-23 10:01 ` Peter Zijlstra 2011-08-23 14:15 ` Wu Fengguang 2011-08-23 14:15 ` Wu Fengguang 2011-08-23 17:47 ` Vivek Goyal 2011-08-23 17:47 ` Vivek Goyal 2011-08-24 0:12 ` Wu Fengguang 2011-08-24 0:12 ` Wu Fengguang 2011-08-24 16:12 ` Peter Zijlstra 2011-08-24 16:12 ` Peter Zijlstra 2011-08-26 0:18 ` Wu Fengguang 2011-08-26 0:18 ` Wu Fengguang 2011-08-26 9:04 ` Peter Zijlstra 2011-08-26 9:04 ` Peter Zijlstra 2011-08-26 10:04 ` Wu Fengguang 2011-08-26 10:04 ` Wu Fengguang 2011-08-26 10:42 ` Peter Zijlstra 2011-08-26 10:42 ` Peter Zijlstra 2011-08-26 10:52 ` Wu Fengguang 2011-08-26 10:52 ` Wu Fengguang 2011-08-26 11:26 ` Wu Fengguang 2011-08-26 12:11 ` Peter Zijlstra 2011-08-26 12:11 ` Peter Zijlstra 2011-08-26 12:20 ` Wu Fengguang 2011-08-26 12:20 ` Wu Fengguang 2011-08-26 13:13 ` Wu Fengguang 2011-08-26 13:18 ` Peter Zijlstra 2011-08-26 13:18 ` Peter Zijlstra 2011-08-26 13:24 ` Wu Fengguang 2011-08-26 13:24 ` Wu Fengguang 2011-08-24 18:00 ` Vivek Goyal 2011-08-24 18:00 ` Vivek Goyal 2011-08-25 3:19 ` Wu Fengguang 2011-08-25 3:19 ` Wu Fengguang 2011-08-25 22:20 ` Vivek Goyal 2011-08-25 22:20 ` Vivek Goyal 2011-08-26 1:56 ` Wu Fengguang 2011-08-26 1:56 ` Wu Fengguang 2011-08-26 8:56 ` Peter Zijlstra 2011-08-26 8:56 ` Peter Zijlstra 2011-08-26 9:53 ` Wu Fengguang 2011-08-26 9:53 ` Wu Fengguang 2011-08-29 13:12 ` Peter Zijlstra 2011-08-29 13:12 ` Peter Zijlstra 2011-08-29 13:37 ` Wu Fengguang 2011-08-29 13:37 ` Wu Fengguang 2011-09-02 12:16 ` Peter Zijlstra 2011-09-02 12:16 ` Peter Zijlstra 2011-09-06 12:40 ` Peter Zijlstra 2011-09-06 12:40 ` Peter Zijlstra 2011-08-24 15:57 ` Peter Zijlstra 2011-08-24 15:57 ` Peter Zijlstra 2011-08-24 15:57 ` Peter Zijlstra 2011-08-25 5:30 ` Wu Fengguang 2011-08-25 5:30 ` Wu Fengguang 2011-08-23 14:36 ` Vivek Goyal 2011-08-23 14:36 ` Vivek Goyal 2011-08-09 2:08 ` Vivek Goyal 2011-08-09 2:08 ` Vivek Goyal 2011-08-16 8:59 ` Wu Fengguang 2011-08-16 8:59 ` Wu Fengguang 2011-08-06 8:44 ` [PATCH 3/5] writeback: dirty rate control Wu Fengguang 2011-08-06 8:44 ` Wu Fengguang 2011-08-06 8:44 ` Wu Fengguang 2011-08-09 14:54 ` Vivek Goyal 2011-08-09 14:54 ` Vivek Goyal 2011-08-11 3:42 ` Wu Fengguang 2011-08-11 3:42 ` Wu Fengguang 2011-08-09 14:57 ` Peter Zijlstra 2011-08-09 14:57 ` Peter Zijlstra 2011-08-09 14:57 ` Peter Zijlstra 2011-08-10 11:07 ` Wu Fengguang 2011-08-10 11:07 ` Wu Fengguang 2011-08-10 16:17 ` Peter Zijlstra 2011-08-10 16:17 ` Peter Zijlstra 2011-08-10 16:17 ` Peter Zijlstra 2011-08-15 14:08 ` Wu Fengguang 2011-08-15 14:08 ` Wu Fengguang 2011-08-09 15:50 ` Vivek Goyal 2011-08-09 15:50 ` Vivek Goyal 2011-08-09 16:16 ` Peter Zijlstra 2011-08-09 16:16 ` Peter Zijlstra 2011-08-09 16:16 ` Peter Zijlstra 2011-08-09 16:19 ` Peter Zijlstra 2011-08-09 16:19 ` Peter Zijlstra 2011-08-09 16:19 ` Peter Zijlstra 2011-08-10 14:07 ` Wu Fengguang 2011-08-10 14:07 ` Wu Fengguang 2011-08-10 14:00 ` Wu Fengguang 2011-08-10 14:00 ` Wu Fengguang 2011-08-10 17:10 ` Peter Zijlstra 2011-08-10 17:10 ` Peter Zijlstra 2011-08-15 14:11 ` Wu Fengguang 2011-08-15 14:11 ` Wu Fengguang 2011-08-09 16:56 ` Peter Zijlstra 2011-08-09 16:56 ` Peter Zijlstra 2011-08-09 16:56 ` Peter Zijlstra 2011-08-10 14:10 ` Wu Fengguang 2011-08-09 17:02 ` Peter Zijlstra 2011-08-09 17:02 ` Peter Zijlstra 2011-08-09 17:02 ` Peter Zijlstra 2011-08-10 14:15 ` Wu Fengguang 2011-08-10 14:15 ` Wu Fengguang 2011-08-06 8:44 ` [PATCH 4/5] writeback: per task dirty rate limit Wu Fengguang 2011-08-06 8:44 ` Wu Fengguang 2011-08-06 8:44 ` Wu Fengguang 2011-08-06 14:35 ` Andrea Righi 2011-08-06 14:35 ` Andrea Righi 2011-08-07 6:19 ` Wu Fengguang 2011-08-07 6:19 ` Wu Fengguang 2011-08-08 13:47 ` Peter Zijlstra 2011-08-08 13:47 ` Peter Zijlstra 2011-08-08 13:47 ` Peter Zijlstra 2011-08-08 14:21 ` Wu Fengguang 2011-08-08 14:21 ` Wu Fengguang 2011-08-08 23:32 ` Wu Fengguang 2011-08-08 23:32 ` Wu Fengguang 2011-08-08 14:23 ` Wu Fengguang 2011-08-08 14:23 ` Wu Fengguang 2011-08-08 14:26 ` Peter Zijlstra 2011-08-08 14:26 ` Peter Zijlstra 2011-08-08 14:26 ` Peter Zijlstra 2011-08-08 22:38 ` Wu Fengguang 2011-08-08 22:38 ` Wu Fengguang 2011-08-13 16:28 ` Andrea Righi 2011-08-13 16:28 ` Andrea Righi 2011-08-15 14:21 ` Wu Fengguang 2011-08-15 14:26 ` Andrea Righi 2011-08-15 14:26 ` Andrea Righi 2011-08-09 17:46 ` Vivek Goyal 2011-08-09 17:46 ` Vivek Goyal 2011-08-10 3:29 ` Wu Fengguang 2011-08-10 3:29 ` Wu Fengguang 2011-08-10 18:18 ` Vivek Goyal 2011-08-10 18:18 ` Vivek Goyal 2011-08-11 0:55 ` Wu Fengguang 2011-08-11 0:55 ` Wu Fengguang 2011-08-09 18:35 ` Peter Zijlstra 2011-08-09 18:35 ` Peter Zijlstra 2011-08-09 18:35 ` Peter Zijlstra 2011-08-10 3:40 ` Wu Fengguang 2011-08-10 3:40 ` Wu Fengguang 2011-08-10 10:25 ` Peter Zijlstra 2011-08-10 10:25 ` Peter Zijlstra 2011-08-10 10:25 ` Peter Zijlstra 2011-08-10 11:13 ` Wu Fengguang 2011-08-10 11:13 ` Wu Fengguang 2011-08-06 8:44 ` [PATCH 5/5] writeback: IO-less balance_dirty_pages() Wu Fengguang 2011-08-06 8:44 ` Wu Fengguang 2011-08-06 8:44 ` Wu Fengguang 2011-08-06 14:48 ` Andrea Righi 2011-08-06 14:48 ` Andrea Righi 2011-08-06 14:48 ` Andrea Righi 2011-08-07 6:44 ` Wu Fengguang 2011-08-07 6:44 ` Wu Fengguang 2011-08-07 6:44 ` Wu Fengguang 2011-08-06 16:46 ` Andrea Righi 2011-08-06 16:46 ` Andrea Righi 2011-08-07 7:18 ` Wu Fengguang 2011-08-07 9:50 ` Andrea Righi 2011-08-07 9:50 ` Andrea Righi 2011-08-09 18:15 ` Vivek Goyal 2011-08-09 18:15 ` Vivek Goyal 2011-08-09 18:41 ` Peter Zijlstra 2011-08-09 18:41 ` Peter Zijlstra 2011-08-09 18:41 ` Peter Zijlstra 2011-08-10 3:22 ` Wu Fengguang 2011-08-10 3:22 ` Wu Fengguang 2011-08-10 3:26 ` Wu Fengguang 2011-08-10 3:26 ` Wu Fengguang 2011-08-09 19:16 ` Vivek Goyal 2011-08-09 19:16 ` Vivek Goyal 2011-08-10 4:33 ` Wu Fengguang 2011-08-09 2:01 ` [PATCH 0/5] IO-less dirty throttling v8 Vivek Goyal 2011-08-09 2:01 ` Vivek Goyal 2011-08-09 5:55 ` Dave Chinner 2011-08-09 5:55 ` Dave Chinner 2011-08-09 14:04 ` Vivek Goyal 2011-08-09 14:04 ` Vivek Goyal 2011-08-10 7:41 ` Greg Thelen 2011-08-10 7:41 ` Greg Thelen 2011-08-10 7:41 ` Greg Thelen 2011-08-10 18:40 ` Vivek Goyal 2011-08-10 18:40 ` Vivek Goyal 2011-08-10 18:40 ` Vivek Goyal 2011-08-11 3:21 ` Wu Fengguang 2011-08-11 3:21 ` Wu Fengguang 2011-08-11 20:42 ` Vivek Goyal 2011-08-11 20:42 ` Vivek Goyal 2011-08-11 21:00 ` Vivek Goyal 2011-08-11 21:00 ` Vivek Goyal 2011-08-16 2:20 [PATCH 0/5] IO-less dirty throttling v9 Wu Fengguang 2011-08-16 2:20 ` [PATCH 2/5] writeback: dirty position control Wu Fengguang 2011-08-16 2:20 ` Wu Fengguang 2011-08-16 2:20 ` Wu Fengguang 2011-08-16 19:41 ` Jan Kara 2011-08-16 19:41 ` Jan Kara 2011-08-17 13:23 ` Wu Fengguang 2011-08-17 13:49 ` Wu Fengguang 2011-08-17 13:49 ` Wu Fengguang 2011-08-17 20:24 ` Jan Kara 2011-08-17 20:24 ` Jan Kara 2011-08-18 4:18 ` Wu Fengguang 2011-08-18 4:18 ` Wu Fengguang 2011-08-18 4:41 ` Wu Fengguang 2011-08-18 4:41 ` Wu Fengguang 2011-08-18 19:16 ` Jan Kara 2011-08-18 19:16 ` Jan Kara 2011-08-24 3:16 ` Wu Fengguang 2011-08-24 3:16 ` Wu Fengguang 2011-08-19 2:53 ` Vivek Goyal 2011-08-19 2:53 ` Vivek Goyal 2011-08-19 3:25 ` Wu Fengguang 2011-08-19 3:25 ` Wu Fengguang [not found] <CAFdhcLRKvfqBnXCXLwq-Qe1eNAGC-8XJ3BtHpQKzaa3RhHyp6A@mail.gmail.com> 2011-08-17 6:40 ` David Horner 2011-08-17 12:03 ` Jan Kara 2011-08-17 12:35 ` Wu Fengguang
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=20110823034042.GC7332@localhost \ --to=fengguang.wu@intel.com \ --cc=akpm@linux-foundation.org \ --cc=arighi@develer.com \ --cc=david@fromorbit.com \ --cc=gthelen@google.com \ --cc=hch@lst.de \ --cc=jack@suse.cz \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=minchan.kim@gmail.com \ --cc=peterz@infradead.org \ --cc=vgoyal@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: linkBe 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.