Re: [Bug #13058] First hibernation attempt fails

Linus Torvalds
2009-04-17T16:00:49Z

On Fri, 17 Apr 2009, Alan Jenkins wrote:
>
> As another datapoint: I tried blindly applying the commit to 2.6.29.
> The resulting kernel was able to hibernate fine the first time.

Yeah, so it's not that commit per se that causes it. I bet it needs all
the IO scheduler changes too - and even when it does that, the end result
probably is really just a timing change.

> I'm going to be annoying and try something slightly different. In
> theory, I should be able to find the "first bad commit" where
> cherry-picking 1faa16d22 causes a problem.

Just for fun, try this one first and see if it makes any difference.

Maybe the whole "swappiness=0" part was intentional. And maybe it wasn't.
This is one trivial patch. Maybe it makes your machine blow up. Who knows?

There are other differences in the shrink_all_memory() path wrt the normal
memory freeing paths, but they are way more subtle. So I'm suggesting
tryign this not becasue I think it's "The Bug(tm)", but because it's an
easy test to make, and maybe it makes a difference.

Linus
---
mm/vmscan.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 39fdfb1..d3595ed 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2113,6 +2113,8 @@ unsigned long shrink_all_memory(unsigned long nr_pages)
struct scan_control sc = {
.gfp_mask = GFP_KERNEL,
.may_unmap = 0,
+ .swap_cluster_max = SWAP_CLUSTER_MAX,
+ .swappiness = vm_swappiness,
.may_writepage = 1,
.isolate_pages = isolate_pages_global,
};