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,
};
--
To unsubscribe from this list: send the line "unsubscribe kernel-testers" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
