[PATCH] vmscan: don't use return value trick when oom_killer_disabled

[PATCH] vmscan: don't use return value trick when oom_killer_disabled

[Minchan Kim]

M. Vefa Bicakci reported 2.6.35 kernel hang up when hibernation on his
32bit 3GB mem machine. (https://bugzilla.kernel.org/show_bug.cgi?id=16771)
Also he was bisected first bad commit is below

  commit bb21c7ce18eff8e6e7877ca1d06c6db719376e3c
  Author: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
  Date:   Fri Jun 4 14:15:05 2010 -0700

     vmscan: fix do_try_to_free_pages() return value when priority==0 reclaim failure

At first impression, this seemed very strange because the above commit only
chenged function return value and hibernate_preallocate_memory() ignore
return value of shrink_all_memory(). But it's related.

Now, page allocation from hibernation code may enter infinite loop if
the system has highmem.

The reasons are two. 1) hibernate_preallocate_memory() call
alloc_pages() wrong order 2) vmscan don't care enough OOM case when
oom_killer_disabled.

This patch only fix (2). Why is oom_killer_disabled so special?
because when hibernation case, zone->all_unreclaimable never be turned on.
hibernation freeze all tasks at first, then kswapd can't works in this
case, and zone->all_unreclaimable is only turned from kswapd.

Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: M. Vefa Bicakci <bicave@superonline.com>
Cc: stable@kernel.org
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
---
 mm/vmscan.c |   33 +++++++++++++++++++++++++++------
 1 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index f620ab3..53b23a7 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1893,12 +1893,11 @@ static void shrink_zone(int priority, struct zone *zone,
  * If a zone is deemed to be full of pinned pages then just give it a light
  * scan then give up on it.
  */
-static bool shrink_zones(int priority, struct zonelist *zonelist,
+static void shrink_zones(int priority, struct zonelist *zonelist,
 					struct scan_control *sc)
 {
 	struct zoneref *z;
 	struct zone *zone;
-	bool all_unreclaimable = true;
 
 	for_each_zone_zonelist_nodemask(zone, z, zonelist,
 					gfp_zone(sc->gfp_mask), sc->nodemask) {
@@ -1916,8 +1915,31 @@ static bool shrink_zones(int priority, struct zonelist *zonelist,
 		}
 
 		shrink_zone(priority, zone, sc);
-		all_unreclaimable = false;
 	}
+}
+
+static inline bool all_unreclaimable(struct zonelist *zonelist,
+		struct scan_control *sc)
+{
+	struct zoneref *z;
+	struct zone *zone;
+	bool all_unreclaimable = true;
+
+	if (!scanning_global_lru(sc))
+		return false;
+
+	for_each_zone_zonelist_nodemask(zone, z, zonelist,
+			gfp_zone(sc->gfp_mask), sc->nodemask) {
+		if (!populated_zone(zone))
+			continue;
+		if (!cpuset_zone_allowed_hardwall(zone, GFP_KERNEL))
+			continue;
+		if (zone->pages_scanned < (zone_reclaimable_pages(zone) * 6)) {
+			all_unreclaimable = false;
+			break;
+		}
+	}
+
 	return all_unreclaimable;
 }
 
@@ -1941,7 +1963,6 @@ static unsigned long do_try_to_free_pages(struct zonelist *zonelist,
 					struct scan_control *sc)
 {
 	int priority;
-	bool all_unreclaimable;
 	unsigned long total_scanned = 0;
 	struct reclaim_state *reclaim_state = current->reclaim_state;
 	struct zoneref *z;
@@ -1958,7 +1979,7 @@ static unsigned long do_try_to_free_pages(struct zonelist *zonelist,
 		sc->nr_scanned = 0;
 		if (!priority)
 			disable_swap_token();
-		all_unreclaimable = shrink_zones(priority, zonelist, sc);
+		shrink_zones(priority, zonelist, sc);
 		/*
 		 * Don't shrink slabs when reclaiming memory from
 		 * over limit cgroups
@@ -2020,7 +2041,7 @@ out:
 		return sc->nr_reclaimed;
 
 	/* top priority shrink_zones still had more to do? don't OOM, then */
-	if (scanning_global_lru(sc) && !all_unreclaimable)
+	if (!all_unreclaimable(zonelist, sc))
 		return 1;
 
 	return 0;
-- 
1.7.0.5

--
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>

Re: [PATCH] vmscan: don't use return value trick when oom_killer_disabled

[Rafael J. Wysocki]

On Thursday, September 02, 2010, Minchan Kim wrote:
> M. Vefa Bicakci reported 2.6.35 kernel hang up when hibernation on his
> 32bit 3GB mem machine. (https://bugzilla.kernel.org/show_bug.cgi?id=16771)
> Also he was bisected first bad commit is below
> 
>   commit bb21c7ce18eff8e6e7877ca1d06c6db719376e3c
>   Author: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
>   Date:   Fri Jun 4 14:15:05 2010 -0700
> 
>      vmscan: fix do_try_to_free_pages() return value when priority==0 reclaim failure
> 
> At first impression, this seemed very strange because the above commit only
> chenged function return value and hibernate_preallocate_memory() ignore
> return value of shrink_all_memory(). But it's related.
> 
> Now, page allocation from hibernation code may enter infinite loop if
> the system has highmem.
> 
> The reasons are two. 1) hibernate_preallocate_memory() call
> alloc_pages() wrong order

This isn't the case, as explained here: http://lkml.org/lkml/2010/9/1/316 .

The ordering of calls is correct, but it's better to check if there are any
non-highmem pages to allocate from before the last call (for performance
reasons, but that also would eliminate the failure in question).

Thanks,
Rafael

--
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>

Re: [PATCH] vmscan: don't use return value trick when oom_killer_disabled

[Minchan Kim]

2010/9/3 Rafael J. Wysocki <rjw@sisk.pl>:
> On Thursday, September 02, 2010, Minchan Kim wrote:
>> M. Vefa Bicakci reported 2.6.35 kernel hang up when hibernation on his
>> 32bit 3GB mem machine. (https://bugzilla.kernel.org/show_bug.cgi?id=16771)
>> Also he was bisected first bad commit is below
>>
>>   commit bb21c7ce18eff8e6e7877ca1d06c6db719376e3c
>>   Author: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
>>   Date:   Fri Jun 4 14:15:05 2010 -0700
>>
>>      vmscan: fix do_try_to_free_pages() return value when priority==0 reclaim failure
>>
>> At first impression, this seemed very strange because the above commit only
>> chenged function return value and hibernate_preallocate_memory() ignore
>> return value of shrink_all_memory(). But it's related.
>>
>> Now, page allocation from hibernation code may enter infinite loop if
>> the system has highmem.
>>
>> The reasons are two. 1) hibernate_preallocate_memory() call
>> alloc_pages() wrong order
>
> This isn't the case, as explained here: http://lkml.org/lkml/2010/9/1/316 .
>
> The ordering of calls is correct, but it's better to check if there are any
> non-highmem pages to allocate from before the last call (for performance
> reasons, but that also would eliminate the failure in question).

I actually didn't look into the 1) problem detail.
Just copy and paste from KOSAKI's description.
As I look the thread, KOSAKI seem to admit the description is wrong.
I will resend the patch removing phrase about 1) problem if KOSAKI don't mind.
KOSAKI. Is it okay?

Thanks.


-- 
Kind regards,
Minchan Kim

--
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>

Re: [PATCH] vmscan: don't use return value trick when oom_killer_disabled

[KOSAKI Motohiro]

> 2010/9/3 Rafael J. Wysocki <rjw@sisk.pl>:
> > On Thursday, September 02, 2010, Minchan Kim wrote:
> >> M. Vefa Bicakci reported 2.6.35 kernel hang up when hibernation on his
> >> 32bit 3GB mem machine. (https://bugzilla.kernel.org/show_bug.cgi?id=16771)
> >> Also he was bisected first bad commit is below
> >>
> >>   commit bb21c7ce18eff8e6e7877ca1d06c6db719376e3c
> >>   Author: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> >>   Date:   Fri Jun 4 14:15:05 2010 -0700
> >>
> >>      vmscan: fix do_try_to_free_pages() return value when priority==0 reclaim failure
> >>
> >> At first impression, this seemed very strange because the above commit only
> >> chenged function return value and hibernate_preallocate_memory() ignore
> >> return value of shrink_all_memory(). But it's related.
> >>
> >> Now, page allocation from hibernation code may enter infinite loop if
> >> the system has highmem.
> >>
> >> The reasons are two. 1) hibernate_preallocate_memory() call
> >> alloc_pages() wrong order
> >
> > This isn't the case, as explained here: http://lkml.org/lkml/2010/9/1/316 .
> >
> > The ordering of calls is correct, but it's better to check if there are any
> > non-highmem pages to allocate from before the last call (for performance
> > reasons, but that also would eliminate the failure in question).
> 
> I actually didn't look into the 1) problem detail.
> Just copy and paste from KOSAKI's description.
> As I look the thread, KOSAKI seem to admit the description is wrong.
> I will resend the patch removing phrase about 1) problem if KOSAKI don't mind.
> KOSAKI. Is it okay?

Yeah! please :)




--
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>