[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20091026100019.2F4A.A69D9226@jp.fujitsu.com>
Date: Mon, 26 Oct 2009 10:11:29 +0900 (JST)
From: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To: Mel Gorman <mel@....ul.ie>
Cc: kosaki.motohiro@...fujitsu.com, Frans Pop <elendil@...net.nl>,
Jiri Kosina <jkosina@...e.cz>,
Sven Geggus <lists@...hsschwanzdomain.de>,
Karol Lewandowski <karol.k.lewandowski@...il.com>,
Tobias Oetiker <tobi@...iker.ch>,
"Rafael J. Wysocki" <rjw@...k.pl>,
David Miller <davem@...emloft.net>,
Reinette Chatre <reinette.chatre@...el.com>,
Kalle Valo <kalle.valo@....fi>,
David Rientjes <rientjes@...gle.com>,
Mohamed Abbas <mohamed.abbas@...el.com>,
Jens Axboe <jens.axboe@...cle.com>,
"John W. Linville" <linville@...driver.com>,
Pekka Enberg <penberg@...helsinki.fi>,
Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
Greg Kroah-Hartman <gregkh@...e.de>,
Stephan von Krawczynski <skraw@...net.com>,
Kernel Testers List <kernel-testers@...r.kernel.org>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
"linux-mm@...ck.org\"" <linux-mm@...ck.org>
Subject: Re: [PATCH 1/5] page allocator: Always wake kswapd when restarting an allocation attempt after direct reclaim failed
> 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 <mel@....ul.ie>
> ---
> 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 <kosaki.motohiro@...fujitsu.com>
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,
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;
}
-------------------------------------------
?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists