Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753132Ab3DLCwy (ORCPT ); Thu, 11 Apr 2013 22:52:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20073 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751504Ab3DLCwx (ORCPT ); Thu, 11 Apr 2013 22:52:53 -0400 Message-ID: <516776CD.4070109@redhat.com> Date: Thu, 11 Apr 2013 22:51:57 -0400 From: Rik van Riel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Mel Gorman CC: Andrew Morton , Jiri Slaby , Valdis Kletnieks , Zlatko Calusic , Johannes Weiner , dormando , Satoru Moriya , Michal Hocko , Linux-MM , LKML Subject: Re: [PATCH 06/10] mm: vmscan: Have kswapd writeback pages based on dirty pages encountered, not priority References: <1365505625-9460-1-git-send-email-mgorman@suse.de> <1365505625-9460-7-git-send-email-mgorman@suse.de> In-Reply-To: <1365505625-9460-7-git-send-email-mgorman@suse.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1285 Lines: 29 On 04/09/2013 07:07 AM, Mel Gorman wrote: > Currently kswapd queues dirty pages for writeback if scanning at an elevated > priority but the priority kswapd scans at is not related to the number > of unqueued dirty encountered. Since commit "mm: vmscan: Flatten kswapd > priority loop", the priority is related to the size of the LRU and the > zone watermark which is no indication as to whether kswapd should write > pages or not. > > This patch tracks if an excessive number of unqueued dirty pages are being > encountered at the end of the LRU. If so, it indicates that dirty pages > are being recycled before flusher threads can clean them and flags the > zone so that kswapd will start writing pages until the zone is balanced. > > Signed-off-by: Mel Gorman I like your approach of essentially not writing out from kswapd if we manage to reclaim well at DEF_PRIORITY, and doing writeout more and more aggressively if we have to reduce priority. Reviewed-by: Rik van Riel -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/