Messages in this thread Patch in this message | | | Date | Fri, 9 Jul 1999 16:22:01 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: [test program] for OOM situations |
| |
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/
| |