From patchwork Mon Oct 26 01:11:29 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: KOSAKI Motohiro X-Patchwork-Id: 36878 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by ozlabs.org (Postfix) with ESMTP id BEFA4B7BDC for ; Mon, 26 Oct 2009 12:11:39 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754443AbZJZBLa (ORCPT ); Sun, 25 Oct 2009 21:11:30 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754254AbZJZBL3 (ORCPT ); Sun, 25 Oct 2009 21:11:29 -0400 Received: from fgwmail6.fujitsu.co.jp ([192.51.44.36]:55037 "EHLO fgwmail6.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754338AbZJZBL2 (ORCPT ); Sun, 25 Oct 2009 21:11:28 -0400 Received: from m6.gw.fujitsu.co.jp ([10.0.50.76]) by fgwmail6.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id n9Q1BWUn008888 (envelope-from kosaki.motohiro@jp.fujitsu.com); Mon, 26 Oct 2009 10:11:32 +0900 Received: from smail (m6 [127.0.0.1]) by outgoing.m6.gw.fujitsu.co.jp (Postfix) with ESMTP id D6FC445DE4E; Mon, 26 Oct 2009 10:11:31 +0900 (JST) Received: from s6.gw.fujitsu.co.jp (s6.gw.fujitsu.co.jp [10.0.50.96]) by m6.gw.fujitsu.co.jp (Postfix) with ESMTP id B111B45DE4C; Mon, 26 Oct 2009 10:11:31 +0900 (JST) Received: from s6.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s6.gw.fujitsu.co.jp (Postfix) with ESMTP id 93FDA1DB8037; Mon, 26 Oct 2009 10:11:31 +0900 (JST) Received: from ml13.s.css.fujitsu.com (ml13.s.css.fujitsu.com [10.249.87.103]) by s6.gw.fujitsu.co.jp (Postfix) with ESMTP id 3FC9AE08001; Mon, 26 Oct 2009 10:11:31 +0900 (JST) Received: from ml13.css.fujitsu.com (ml13 [127.0.0.1]) by ml13.s.css.fujitsu.com (Postfix) with ESMTP id E5CA9FD0002; Mon, 26 Oct 2009 10:11:30 +0900 (JST) Received: from [127.0.0.1] (unknown [10.124.100.179]) by ml13.s.css.fujitsu.com (Postfix) with ESMTP id E525FFD0001; Mon, 26 Oct 2009 10:11:29 +0900 (JST) X-SecurityPolicyCheck-FJ: OK by FujitsuOutboundMailChecker v1.3.1 Received: from KOSANOTE2[10.124.100.179] by KOSANOTE2 (FujitsuOutboundMailChecker v1.3.1/9992[10.124.100.179]); Mon, 26 Oct 2009 10:11:38 +0900 (JST) From: KOSAKI Motohiro To: Mel Gorman Subject: Re: [PATCH 1/5] page allocator: Always wake kswapd when restarting an allocation attempt after direct reclaim failed Cc: kosaki.motohiro@jp.fujitsu.com, Frans Pop , Jiri Kosina , Sven Geggus , Karol Lewandowski , Tobias Oetiker , "Rafael J. Wysocki" , David Miller , Reinette Chatre , Kalle Valo , David Rientjes , Mohamed Abbas , Jens Axboe , "John W. Linville" , Pekka Enberg , Bartlomiej Zolnierkiewicz , Greg Kroah-Hartman , Stephan von Krawczynski , Kernel Testers List , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, "linux-mm@kvack.org\"" In-Reply-To: <1256221356-26049-2-git-send-email-mel@csn.ul.ie> References: <1256221356-26049-1-git-send-email-mel@csn.ul.ie> <1256221356-26049-2-git-send-email-mel@csn.ul.ie> Message-Id: <20091026100019.2F4A.A69D9226@jp.fujitsu.com> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.50.07 [ja] Date: Mon, 26 Oct 2009 10:11:29 +0900 (JST) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > If a direct reclaim makes no forward progress, it considers whether it > should go OOM or not. Whether OOM is triggered or not, it may retry the > application afterwards. In times past, this would always wake kswapd as well > but currently, kswapd is not woken up after direct reclaim fails. For order-0 > allocations, this makes little difference but if there is a heavy mix of > higher-order allocations that direct reclaim is failing for, it might mean > that kswapd is not rewoken for higher orders as much as it did previously. > > This patch wakes up kswapd when an allocation is being retried after a direct > reclaim failure. It would be expected that kswapd is already awake, but > this has the effect of telling kswapd to reclaim at the higher order as well. > > Signed-off-by: Mel Gorman > --- > mm/page_alloc.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index bf72055..dfa4362 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -1817,9 +1817,9 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, > if (NUMA_BUILD && (gfp_mask & GFP_THISNODE) == GFP_THISNODE) > goto nopage; > > +restart: > wake_all_kswapd(order, zonelist, high_zoneidx); > > -restart: > /* > * OK, we're below the kswapd watermark and have kicked background > * reclaim. Now things get more complex, so set up alloc_flags according I think this patch is correct. personally, I like to add some commnent at restart label. but it isn't big matter. Reviewed-by: KOSAKI Motohiro However, I have a question. __alloc_pages_slowpath() retry logic is, 1. try_to_free_pages() reclaimed some pages: -> wait awhile and goto rebalance 2. try_to_free_pages() didn't reclaimed any page: -> call out_of_memory() and goto restart Then, case-1 should be fixed too? I mean, ------------------------------------------- ? --- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/mm/page_alloc.c b/mm/page_alloc.c index bf72055..5a27896 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -1899,6 +1899,12 @@ rebalance: if (should_alloc_retry(gfp_mask, order, pages_reclaimed)) { /* Wait for some write requests to complete then retry */ congestion_wait(BLK_RW_ASYNC, HZ/50); + + /* + * While we wait congestion wait, Amount of free memory can + * be changed dramatically. Thus, we kick kswapd again. + */ + wake_all_kswapd(order, zonelist, high_zoneidx); goto rebalance; }