Re: Kernel 2.6.8.1: swap storm of death - nr_requests > 1024 on swap partition

Marcelo Tosatti
2004-08-30T20:33:39Z

On Mon, Aug 30, 2004 at 08:01:19PM +0200, Karl Vogel wrote:
> Marcelo Tosatti wrote:
>
> >What is the problem Karl is seeing again? There seem to be several, lets
> >separate them
> >
> >- OOM killer triggering (if there's swap space available and
> >"enough" anonymous memory to be swapped out this should not happen).
> >One of his complaint on the initial report (about the OOM killer).
>
> Correct. On my 512Mb RAM system with 1Gb swap partition, running a
> calloc(1Gb) causes the process to get OOM killed when using CFQ.
> The problem is not CFQ as such.. the problem is when nr_requests is too
> large (8192 being the default for CFQ).
>
> The same will happen with the default nr_request of 128 which AS uses,
> if you use a low memory system. e.g. I booted with mem=128M and then a
> calloc(128Mb) can trigger the OOM.

Karl,

Can you please try the following - it limits the number of in-flight writeback
pages to 25% of total RAM at the VM level.

Does wonders for me with 8192 nr_requests. The hogs finish _much_ faster and
and interactivity feels much better.

With nr_requests=128, this limit is not reached (probably never), but with 8192,
it certainly does.

--- a/mm/vmscan.c 2004-08-30 17:50:25.000000000 -0300
+++ b/mm/vmscan.c 2004-08-30 18:34:54.666423368 -0300
@@ -247,6 +247,12 @@

static int may_write_to_queue(struct backing_dev_info *bdi)
{
+ int nr_writeback = read_page_state(nr_writeback);
+
+ if (nr_writeback > (totalram_pages * 25 / 100)) {
+ blk_congestion_wait(WRITE, HZ/5);
+ return 0;
+ }
if (current_is_kswapd())
return 1;
if (current_is_pdflush()) /* This is unlikely, but why not... */