xfs
[Top] [All Lists]

Re: [PATCH 5/7] mm: vmscan: Do not writeback filesystem pages in kswapd

To: Mel Gorman <mgorman@xxxxxxx>
Subject: Re: [PATCH 5/7] mm: vmscan: Do not writeback filesystem pages in kswapd except in high priority
From: Rik van Riel <riel@xxxxxxxxxx>
Date: Thu, 11 Aug 2011 14:18:54 -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-6-git-send-email-mgorman@xxxxxxx>
References: <1312973240-32576-1-git-send-email-mgorman@xxxxxxx> <1312973240-32576-6-git-send-email-mgorman@xxxxxxx>
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.7) 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:
It is preferable that no dirty pages are dispatched for cleaning from
the page reclaim path. At normal priorities, this patch prevents kswapd
writing pages.

However, page reclaim does have a requirement that pages be freed
in a particular zone. If it is failing to make sufficient progress
(reclaiming<  SWAP_CLUSTER_MAX at any priority priority), the priority
is raised to scan more pages. A priority of DEF_PRIORITY - 3 is
considered to be the point where kswapd is getting into trouble
reclaiming pages. If this priority is reached, kswapd will dispatch
pages for writing.

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

My only worry with this patch is that maybe we'll burn too
much CPU time freeing pages from a zone.  However, chances
are we'll have freed pages from other zones when scanning
one zone multiple times (the page cache dirty limit is global,
the clean pages have to be _somewhere_).

Since the bulk of the allocators are not too picky about
which zone they get their pages from, I suspect this patch
will be an overall improvement pretty much all the time.

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

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