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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jul 23 2003 - 22:00:35 EST