From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p7BIJ9e1260822 for ; Thu, 11 Aug 2011 13:19:10 -0500 Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9999C18AEA50 for ; Thu, 11 Aug 2011 11:19:08 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 4mLibodW0a6oxQSw for ; Thu, 11 Aug 2011 11:19:08 -0700 (PDT) Message-ID: <4E441D0E.6020602@redhat.com> Date: Thu, 11 Aug 2011 14:18:54 -0400 From: Rik van Riel MIME-Version: 1.0 Subject: Re: [PATCH 5/7] mm: vmscan: Do not writeback filesystem pages in kswapd except in high priority References: <1312973240-32576-1-git-send-email-mgorman@suse.de> <1312973240-32576-6-git-send-email-mgorman@suse.de> In-Reply-To: <1312973240-32576-6-git-send-email-mgorman@suse.de> List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xfs-bounces@oss.sgi.com Errors-To: xfs-bounces@oss.sgi.com To: Mel Gorman Cc: Jan Kara , LKML , XFS , Christoph Hellwig , Linux-MM , Minchan Kim , Wu Fengguang , Johannes Weiner 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 > Reviewed-by: Minchan Kim 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 _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs