Dear KOSAKI
In my test, I didn't set compaction. Maybe compaction is helpful to avoid this issue. I can have try later.
In my mind CONFIG_COMPACTION is an optional configuration right?
If we don't use, and met such an issue, how should we deal with such infinite loop?
I made a change in all_reclaimable() function, passed overnight tests, please help review, thanks in advance!
@@ -2353,7 +2353,9 @@ static bool all_unreclaimable(struct zonelist *zonelist,
continue;
if (!cpuset_zone_allowed_hardwall(zone, GFP_KERNEL))
continue;
- if (!zone->all_unreclaimable)
+ if (zone->all_unreclaimable)
+ continue;
+ if (zone_reclaimable(zone))
return false;
}
Thanks!
Best Regards
Lisa Du
-----Original Message-----
From: KOSAKI Motohiro [mailto:kosaki.motohiro@xxxxxxxxx]
Sent: 2013年7月26日 2:19
To: Lisa Du
Cc: Christoph Lameter; linux-mm@xxxxxxxxx; Mel Gorman; Bob Liu
Subject: Re: Possible deadloop in direct reclaim?
On Tue, Jul 23, 2013 at 9:21 PM, Lisa Du <cldu@xxxxxxxxxxx> wrote:
> Dear Christoph
> Thanks a lot for your comment. When this issue happen I just trigger a kernel panic and got the kdump.
> From the kdump, I got the global variable pg_data_t congit_page_data. From this structure, I can see in normal zone, only order-0's nr_free = 18442, order-1's nr_free = 367, all the other order's nr_free is 0.
Don't you use compaction? Of if use, please get a log by tracepoints.
We need to know why it doesn't work.
?韬{.n???檩jg???a?旃???)钋???骅w+h?璀?ｙ/i?⒏??⒎???Щ ??m?? ?)钋???痂?^??觥??ザ?v???O璁?f??i?⒏?