Re: Software suspend testing in 2.6.0-test1

Andrew Morton
2003-07-18T20:08:05Z

Peter Osterlund <petero2@telia.com> wrote:
>
> The patch below works, but doesn't really solve anything, because it
> is just as slow as the original code.

That's OK - it's a step in the right direction.

> This is not surprising because
> it is still balance_pgdat() that does the page freeing, the only
> difference being that it is now called from kswapd which is woken up
> by the alloc_page() call.

Yup. Probaby we should not be throttling kswapd if it is making good
progress, but this needs broad testing and thought. Something like this,
untested:

--- 25/mm/vmscan.c~less-kswapd-throttling Thu Jul 17 15:35:09 2003
+++ 25-akpm/mm/vmscan.c Thu Jul 17 15:35:12 2003
@@ -930,7 +930,8 @@ static int balance_pgdat(pg_data_t *pgda
}
if (all_zones_ok)
break;
- blk_congestion_wait(WRITE, HZ/10);
+ if (to_free)
+ blk_congestion_wait(WRITE, HZ/10);
}
return nr_pages - to_free;
}

> Note that I had to use HZ/5 in free_some_memory() or else the loop
> would terminate too early. The main problem seems to be that
> balance_pgdat() is too slow when freeing memory. The function can fail
> to free memory in the inner loop either because the disk is congested
> or because too few pages are scanned, but in both cases the function
> calls blk_congestion_wait(), and in the second case the disk may be
> idle and then blk_congestion_wait() doesn't return until the timeout
> expires.

hm, perhaps because kswapd is throttled rather than doing work.

Try the above change, see if you still need the extended timeout in
free_some_memory().

Also, play around with using __GFP_WAIT|__GFP_HIGH|__GFP_NORETRY rather
than GFP_ATOMIC.