lkml.org 
[lkml]   [1999]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.083 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site