Re: [test program] for OOM situations

Andrea Arcangeli (andrea@suse.de)
Fri, 9 Jul 1999 16:22:01 +0200 (CEST)


On Thu, 1 Jul 1999, Bernhard Kaindl wrote:

>Having set up swap size <=128 MB (e.g. 128000 blocks) i've same good
>response with 2.2.10 as with 2.0.37 and 2.3.9pre8.

With the swapin-deadlock fixed properly I was not able to deadlock the
machine anymore... except when using swapfiles > 128mbyte (swap version
2). The probelem is been pointed out to me by Bernd. The bug is that the
header page of the swapfile, was considered a "usable" page for swapout
data. So nr_swap_pages never reached 0. So the complexity of get_swap_page
and so of swap_out() was increasing of an order of magnitude during OOM
conditions. It wasn't a deadlock but the complexity of the code grown so
much that I had to wait more than 5 minutes to get the faulting task
killed.

(btw mkswap calls the new swap header as `version 1', while the kernel
calls it `version 2' and the on-disk signature is SWAPSPACE2 and not
SWAPSPACE1... :)

With the bug fixed now the faulting task gets killed in less than one
second. Here it is the fix against 2.2.10. I propose it for inclusion into
2.2.11:

Index: linux/mm/swapfile.c
===================================================================
RCS file: /var/cvs/linux/mm/swapfile.c,v
retrieving revision 1.1.1.3.2.6
diff -u -r1.1.1.3.2.6 swapfile.c
--- linux/mm/swapfile.c 1999/07/06 01:08:42 1.1.1.3.2.6
+++ linux/mm/swapfile.c 1999/07/09 13:58:59
@@ -688,7 +688,9 @@
else
p->swap_map[page] = SWAP_MAP_BAD;
}
- nr_good_pages = swap_header->info.last_page - i;
+ nr_good_pages = swap_header->info.last_page -
+ swap_header->info.nr_badpages -
+ 1 /* header page */;
if (error)
goto bad_swap;
}

(btw, using i or swap_header->info.nr_badpages is the same thing in such
place, but looks more robust using swap_header->info.nr_badpages :)

Andrea

PS. Bernd could you repeat your OOM test with this patch applyed on the
top of the previous OOM fixes?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/