On Sun, 19 Jun 2011 23:55:47 +0800 Wu Fengguang <fengguang.wu@xxxxxxxxx> wrote: > On Sun, Jun 19, 2011 at 11:36:37PM +0800, Christoph Hellwig wrote: > > On Sun, Jun 19, 2011 at 11:01:11PM +0800, Wu Fengguang wrote: > > > The start of a heavy weight application (ie. KVM) may instantly knock > > > down determine_dirtyable_memory() and hence the global/bdi dirty > > > thresholds. > > > > > > So introduce global_dirty_limit for tracking the global dirty threshold > > > with policies > > > > > > - follow downwards slowly > > > - follow up in one shot > > > > > > global_dirty_limit can effectively mask out the impact of sudden drop of > > > dirtyable memory. It will be used in the next patch for two new type of > > > dirty limits. > > > > This needs to be explained in more detail in comments near the actual > > code. > > Good point! This is the added comment for the update_dirty_limit() function. > > /* > * The global dirtyable memory and dirty threshold could be suddenly knocked > * down by a large amount (eg. on the startup of KVM). This may throw the > * system into deep dirty exceeded state and throttled to "death" for a couple > * of seconds. The solution is to maintain global_dirty_limit for tracking > * slowly down to the knocked down dirty threshold. > */ > static void update_dirty_limit(unsigned long thresh, > unsigned long dirty) > Neither this nor the changelog explain things well. Looking at the code, KVM starts, allocates memory, global_page_state(NR_FREE_PAGES) decreases by N and global_reclaimable_pages() increases by N. Nothing changed. So what's going on here? -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
