Linus Torvalds wrote:
> 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,
> };
>
No, that doesn't seem to affect it.
Thanks
Alan
--
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
