From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
To: Mel Gorman <mel@csn.ul.ie>
Cc: kosaki.motohiro@jp.fujitsu.com,
LKML <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
Nick Piggin <npiggin@suse.de>,
wassim dagash <wassim.dagash@gmail.com>
Subject: [PATCH] mm: stop kswapd's infinite loop at high order allocation take2
Date: Thu, 1 Jan 2009 23:52:02 +0900 (JST) [thread overview]
Message-ID: <20090101021240.A057.KOSAKI.MOTOHIRO@jp.fujitsu.com> (raw)
In-Reply-To: <20081231215934.1296.KOSAKI.MOTOHIRO@jp.fujitsu.com>
> > /*
> > * Fragmentation may mean that the system cannot be
> > * rebalanced for high-order allocations in all zones.
> > * At this point, if nr_reclaimed < SWAP_CLUSTER_MAX,
> > * it means the zones have been fully scanned and are still
> > * not balanced. For high-order allocations, there is
> > * little point trying all over again as kswapd may
> > * infinite loop.
> > *
> > * Instead, recheck all watermarks at order-0 as they
> > * are the most important. If watermarks are ok, kswapd will go
> > * back to sleep. High-order users can still direct reclaim
> > * if they wish.
> > */
> >
> > ?
>
> Excellent. I strongly like this and I hope merge it to my patch.
> I'll resend new patch.
Done.
==
From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Subject: [PATCH] mm: kswapd stop infinite loop at high order allocation
Wassim Dagash reported following kswapd infinite loop problem.
kswapd runs in some infinite loop trying to swap until order 10 of zone
highmem is OK.... kswapd will continue to try to balance order 10 of zone
highmem forever (or until someone release a very large chunk of highmem).
For non order-0 allocations, the system may never be balanced due to
fragmentation but kswapd should not infinitely loop as a result.
Instead, recheck all watermarks at order-0 as they are the most important.
If watermarks are ok, kswapd will go back to sleep.
Reported-by: wassim dagash <wassim.dagash@gmail.com>
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Reviewed-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Mel Gorman <mel@csn.ul.ie>,
---
mm/vmscan.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
Index: b/mm/vmscan.c
===================================================================
--- a/mm/vmscan.c 2008-12-25 08:26:37.000000000 +0900
+++ b/mm/vmscan.c 2009-01-01 01:56:02.000000000 +0900
@@ -1872,6 +1872,23 @@ out:
try_to_freeze();
+ /*
+ * Fragmentation may mean that the system cannot be
+ * rebalanced for high-order allocations in all zones.
+ * At this point, if nr_reclaimed < SWAP_CLUSTER_MAX,
+ * it means the zones have been fully scanned and are still
+ * not balanced. For high-order allocations, there is
+ * little point trying all over again as kswapd may
+ * infinite loop.
+ *
+ * Instead, recheck all watermarks at order-0 as they
+ * are the most important. If watermarks are ok, kswapd will go
+ * back to sleep. High-order users can still direct reclaim
+ * if they wish.
+ */
+ if (nr_reclaimed < SWAP_CLUSTER_MAX)
+ order = sc.order = 0;
+
goto loop_again;
}
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2009-01-01 14:52 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-30 10:55 [PATCH] mm: stop kswapd's infinite loop at high order allocation KOSAKI Motohiro
2008-12-30 11:10 ` Nick Piggin
2008-12-30 18:59 ` Mel Gorman
2008-12-31 1:32 ` Nick Piggin
2008-12-31 11:06 ` Mel Gorman
2008-12-31 11:16 ` Nick Piggin
2008-12-31 12:11 ` Mel Gorman
2008-12-31 4:54 ` KOSAKI Motohiro
2008-12-31 8:59 ` wassim dagash
2008-12-31 12:05 ` Mel Gorman
2008-12-31 12:24 ` wassim dagash
2008-12-31 11:53 ` Mel Gorman
2008-12-31 13:34 ` KOSAKI Motohiro
2009-01-01 14:52 ` KOSAKI Motohiro [this message]
2009-01-02 9:55 ` [PATCH] mm: stop kswapd's infinite loop at high order allocation take2 MinChan Kim
2009-01-02 10:00 ` KOSAKI Motohiro
2009-01-02 10:29 ` MinChan Kim
2009-01-02 10:54 ` KOSAKI Motohiro
2009-01-02 11:18 ` MinChan Kim
2009-01-02 11:14 ` Mel Gorman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090101021240.A057.KOSAKI.MOTOHIRO@jp.fujitsu.com \
--to=kosaki.motohiro@jp.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=npiggin@suse.de \
--cc=wassim.dagash@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox