Messages in this thread | | | Date | Fri, 9 Jul 1999 20:34:23 +0200 (MEST) | From | Bernd Kaindl <> | Subject | Re: [test program] for OOM situations |
| |
On Fri, 9 Jul 1999, Andrea Arcangeli wrote: > > 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.
Yes, this was also my observation.
> 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:
Confirmed, Linus?
> > 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?
Did it, retested on a 4 processor machine, ran all sorts of memory hogs that easyly knocked out the machine before, so I can say that your patches are a step forward and at least the really critical fixes should go into 2.2.11.
But after some additional testing, I've able to kill the userspace again. The kernel was still running, but the SYSRQ-S Emergency sync did'nt work again, also not after much SYSRQ-I. SYSRQ-T still showed my hogs and SYSRQ-P showed stext_lock most of the time. The second function i saw was in stext_lock.
Here the exact EIP's:
80111128 (often) 80111136 (once) 801111ae (once) 801fa904 (neary every EIP) 801fa90b (often)
Here my System.map:
801110fc T do_check_pgt_cache 801111bc T __bad_pagetable
801fa330 T stext_lock 801fe884 r error_table
Maybe I can look into this...
Bernd
- 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/
| |