linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Wu Fengguang <fengguang.wu@intel.com>
To: Mel Gorman <mel@csn.ul.ie>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Dave Chinner <david@fromorbit.com>,
	Chris Mason <chris.mason@oracle.com>,
	Nick Piggin <npiggin@suse.de>, Rik van Riel <riel@redhat.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Christoph Hellwig <hch@infradead.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andrea Arcangeli <aarcange@redhat.com>
Subject: Re: [PATCH 8/8] vmscan: Kick flusher threads to clean pages when reclaim is encountering dirty pages
Date: Mon, 26 Jul 2010 15:28:32 +0800	[thread overview]
Message-ID: <20100726072832.GB13076@localhost> (raw)
In-Reply-To: <1279545090-19169-9-git-send-email-mel@csn.ul.ie>

On Mon, Jul 19, 2010 at 09:11:30PM +0800, Mel Gorman wrote:
> There are a number of cases where pages get cleaned but two of concern
> to this patch are;
>   o When dirtying pages, processes may be throttled to clean pages if
>     dirty_ratio is not met.
>   o Pages belonging to inodes dirtied longer than
>     dirty_writeback_centisecs get cleaned.
> 
> The problem for reclaim is that dirty pages can reach the end of the LRU
> if pages are being dirtied slowly so that neither the throttling cleans
> them or a flusher thread waking periodically.
> 
> Background flush is already cleaning old or expired inodes first but the
> expire time is too far in the future at the time of page reclaim. To mitigate
> future problems, this patch wakes flusher threads to clean 1.5 times the
> number of dirty pages encountered by reclaimers. The reasoning is that pages
> were being dirtied at a roughly constant rate recently so if N dirty pages
> were encountered in this scan block, we are likely to see roughly N dirty
> pages again soon so try keep the flusher threads ahead of reclaim.
> 
> This is unfortunately very hand-wavy but there is not really a good way of
> quantifying how bad it is when reclaim encounters dirty pages other than
> "down with that sort of thing". Similarly, there is not an obvious way of
> figuring how what percentage of dirty pages are old in terms of LRU-age and
> should be cleaned. Ideally, the background flushers would only be cleaning
> pages belonging to the zone being scanned but it's not clear if this would
> be of benefit (less IO) or not (potentially less efficient IO if an inode
> is scattered across multiple zones).
> 
> Signed-off-by: Mel Gorman <mel@csn.ul.ie>
> ---
>  mm/vmscan.c |   18 +++++++++++-------
>  1 files changed, 11 insertions(+), 7 deletions(-)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index bc50937..5763719 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -806,6 +806,8 @@ restart_dirty:
>  		}
>  
>  		if (PageDirty(page))  {
> +			nr_dirty++;
> +
>  			/*
>  			 * If the caller cannot writeback pages, dirty pages
>  			 * are put on a separate list for cleaning by either
> @@ -814,7 +816,6 @@ restart_dirty:
>  			if (!reclaim_can_writeback(sc, page)) {
>  				list_add(&page->lru, &dirty_pages);
>  				unlock_page(page);
> -				nr_dirty++;
>  				goto keep_dirty;
>  			}
>  
> @@ -933,13 +934,16 @@ keep_dirty:
>  		VM_BUG_ON(PageLRU(page) || PageUnevictable(page));
>  	}
>  
> +	/*
> +	 * If reclaim is encountering dirty pages, it may be because
> +	 * dirty pages are reaching the end of the LRU even though
> +	 * the dirty_ratio may be satisified. In this case, wake
> +	 * flusher threads to pro-actively clean some pages
> +	 */
> +	wakeup_flusher_threads(laptop_mode ? 0 : nr_dirty + nr_dirty / 2);

Ah it's very possible that nr_dirty==0 here! Then you are hitting the
number of dirty pages down to 0 whether or not pageout() is called.

Another minor issue is, the passed (nr_dirty + nr_dirty / 2) is
normally a small number, much smaller than MAX_WRITEBACK_PAGES.
The flusher will sync at least MAX_WRITEBACK_PAGES pages, this is good
for efficiency. And it seems good to let the flusher write much more
than nr_dirty pages to safeguard a reasonable large
vmscan-head-to-first-dirty-LRU-page margin. So it would be enough to
update the comments.

Thanks,
Fengguang

>  	if (dirty_isolated < MAX_SWAP_CLEAN_WAIT && !list_empty(&dirty_pages)) {
> -		/*
> -		 * Wakeup a flusher thread to clean at least as many dirty
> -		 * pages as encountered by direct reclaim. Wait on congestion
> -		 * to throttle processes cleaning dirty pages
> -		 */
> -		wakeup_flusher_threads(nr_dirty);
> +		/* Throttle direct reclaimers cleaning pages */
>  		congestion_wait(BLK_RW_ASYNC, HZ/10);
>  
>  		/*
> -- 
> 1.7.1

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2010-07-26  7:28 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-19 13:11 [PATCH 0/8] Reduce writeback from page reclaim context V4 Mel Gorman
2010-07-19 13:11 ` [PATCH 1/8] vmscan: tracing: Roll up of patches currently in mmotm Mel Gorman
2010-07-19 13:11 ` [PATCH 2/8] vmscan: tracing: Update trace event to track if page reclaim IO is for anon or file pages Mel Gorman
2010-07-19 13:24   ` Rik van Riel
2010-07-19 14:15   ` Christoph Hellwig
2010-07-19 14:24     ` Mel Gorman
2010-07-19 14:26       ` Christoph Hellwig
2010-07-19 13:11 ` [PATCH 3/8] vmscan: tracing: Update post-processing script to distinguish between anon and file IO from page reclaim Mel Gorman
2010-07-19 13:32   ` Rik van Riel
2010-07-19 13:11 ` [PATCH 4/8] vmscan: Do not writeback filesystem pages in direct reclaim Mel Gorman
2010-07-19 14:19   ` Christoph Hellwig
2010-07-19 14:26     ` Mel Gorman
2010-07-19 18:25   ` Rik van Riel
2010-07-19 22:14   ` Johannes Weiner
2010-07-20 13:45     ` Mel Gorman
2010-07-20 22:02       ` Johannes Weiner
2010-07-21 11:36         ` Johannes Weiner
2010-07-21 11:52         ` Mel Gorman
2010-07-21 12:01           ` KAMEZAWA Hiroyuki
2010-07-21 14:27             ` Mel Gorman
2010-07-21 23:57               ` KAMEZAWA Hiroyuki
2010-07-22  9:19                 ` Mel Gorman
2010-07-22  9:22                   ` KAMEZAWA Hiroyuki
2010-07-21 13:04           ` Johannes Weiner
2010-07-21 13:38             ` Mel Gorman
2010-07-21 14:28               ` Johannes Weiner
2010-07-21 14:31                 ` Mel Gorman
2010-07-21 14:39                   ` Johannes Weiner
2010-07-21 15:06                     ` Mel Gorman
2010-07-26  8:29               ` Wu Fengguang
2010-07-26  9:12                 ` Mel Gorman
2010-07-26 11:19                   ` Wu Fengguang
2010-07-26 12:53                     ` Mel Gorman
2010-07-26 13:03                       ` Wu Fengguang
2010-07-19 13:11 ` [PATCH 5/8] fs,btrfs: Allow kswapd to writeback pages Mel Gorman
2010-07-19 18:27   ` Rik van Riel
2010-07-19 13:11 ` [PATCH 6/8] fs,xfs: " Mel Gorman
2010-07-19 14:20   ` Christoph Hellwig
2010-07-19 14:43     ` Mel Gorman
2010-07-19 13:11 ` [PATCH 7/8] writeback: sync old inodes first in background writeback Mel Gorman
2010-07-19 14:21   ` Christoph Hellwig
2010-07-19 14:40     ` Mel Gorman
2010-07-19 14:48       ` Christoph Hellwig
2010-07-22  8:52       ` Wu Fengguang
2010-07-22  9:02         ` Wu Fengguang
2010-07-22  9:21         ` Wu Fengguang
2010-07-22 10:48           ` Mel Gorman
2010-07-23  9:45             ` Wu Fengguang
2010-07-23 10:57               ` Mel Gorman
2010-07-23 11:49                 ` Wu Fengguang
2010-07-23 12:20                   ` Wu Fengguang
2010-07-25 10:43                 ` KOSAKI Motohiro
2010-07-25 12:03                   ` Minchan Kim
2010-07-26  3:27                     ` Wu Fengguang
2010-07-26  4:11                       ` Minchan Kim
2010-07-26  4:37                         ` Wu Fengguang
2010-07-26 16:30                           ` Minchan Kim
2010-07-26 22:48                             ` Wu Fengguang
2010-07-26  3:08                   ` Wu Fengguang
2010-07-26  3:11                     ` Rik van Riel
2010-07-26  3:17                       ` Wu Fengguang
2010-07-22 15:34           ` Minchan Kim
2010-07-23 11:59             ` Wu Fengguang
2010-07-22  9:42         ` Mel Gorman
2010-07-23  8:33           ` Wu Fengguang
2010-07-22  1:13     ` Wu Fengguang
2010-07-19 18:43   ` Rik van Riel
2010-07-19 13:11 ` [PATCH 8/8] vmscan: Kick flusher threads to clean pages when reclaim is encountering dirty pages Mel Gorman
2010-07-19 14:23   ` Christoph Hellwig
2010-07-19 14:37     ` Mel Gorman
2010-07-19 22:48       ` Johannes Weiner
2010-07-20 14:10         ` Mel Gorman
2010-07-20 22:05           ` Johannes Weiner
2010-07-19 18:59   ` Rik van Riel
2010-07-19 22:26   ` Johannes Weiner
2010-07-26  7:28   ` Wu Fengguang [this message]
2010-07-26  9:26     ` Mel Gorman
2010-07-26 11:27       ` Wu Fengguang
2010-07-26 12:57         ` Mel Gorman
2010-07-26 13:10           ` Wu Fengguang
2010-07-27 13:35             ` Mel Gorman
2010-07-27 14:24               ` Wu Fengguang
2010-07-27 14:34                 ` Wu Fengguang
2010-07-27 14:40                   ` Mel Gorman
2010-07-27 14:55                     ` Wu Fengguang
2010-07-27 14:38                 ` Mel Gorman
2010-07-27 15:21                   ` 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=20100726072832.GB13076@localhost \
    --to=fengguang.wu@intel.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=chris.mason@oracle.com \
    --cc=david@fromorbit.com \
    --cc=hannes@cmpxchg.org \
    --cc=hch@infradead.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    --cc=npiggin@suse.de \
    --cc=riel@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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).