[Top] [All Lists]

Re: [PATCH 1/7] mm: vmscan: Do not writeback filesystem pages in direct

To: Mel Gorman <mgorman@xxxxxxx>
Subject: Re: [PATCH 1/7] mm: vmscan: Do not writeback filesystem pages in direct reclaim
From: Rik van Riel <riel@xxxxxxxxxx>
Date: Thu, 11 Aug 2011 11:57:36 -0400
Cc: Linux-MM <linux-mm@xxxxxxxxx>, LKML <linux-kernel@xxxxxxxxxxxxxxx>, XFS <xfs@xxxxxxxxxxx>, Dave Chinner <david@xxxxxxxxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>, Johannes Weiner <jweiner@xxxxxxxxxx>, Wu Fengguang <fengguang.wu@xxxxxxxxx>, Jan Kara <jack@xxxxxxx>, Minchan Kim <minchan.kim@xxxxxxxxx>
In-reply-to: <1312973240-32576-2-git-send-email-mgorman@xxxxxxx>
References: <1312973240-32576-1-git-send-email-mgorman@xxxxxxx> <1312973240-32576-2-git-send-email-mgorman@xxxxxxx>
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100720 Fedora/3.1.1-1.fc13 Lightning/1.0b2pre Thunderbird/3.1.1
On 08/10/2011 06:47 AM, Mel Gorman wrote:
From: Mel Gorman<mel@xxxxxxxxx>

When kswapd is failing to keep zones above the min watermark, a process
will enter direct reclaim in the same manner kswapd does. If a dirty
page is encountered during the scan, this page is written to backing
storage using mapping->writepage.

This causes two problems. First, it can result in very deep call
stacks, particularly if the target storage or filesystem are complex.
Some filesystems ignore write requests from direct reclaim as a result.
The second is that a single-page flush is inefficient in terms of IO.
While there is an expectation that the elevator will merge requests,
this does not always happen. Quoting Christoph Hellwig;

        The elevator has a relatively small window it can operate on,
        and can never fix up a bad large scale writeback pattern.

This patch prevents direct reclaim writing back filesystem pages by
checking if current is kswapd. Anonymous pages are still written to
swap as there is not the equivalent of a flusher thread for anonymous
pages. If the dirty pages cannot be written back, they are placed
back on the LRU lists. There is now a direct dependency on dirty page
balancing to prevent too many pages in the system being dirtied which
would prevent reclaim making forward progress.

Signed-off-by: Mel Gorman<mgorman@xxxxxxx>
Reviewed-by: Minchan Kim<minchan.kim@xxxxxxxxx>

Reviewed-by: Rik van Riel <riel@xxxxxxxxxx>

<Prev in Thread] Current Thread [Next in Thread>