Re: oom killer in 2.4.23

[Andrea Arcangeli <andrea@suse.de>]

On Sat, Dec 06, 2003 at 10:31:43AM +0100, Kristian Peters wrote:
> Andrea Arcangeli <andrea@suse.de> schrieb:
> > what you're complaining is the 'selection of the task to be killed'.
> > That's not solvable. the kernel can't read your brain period. Only if
> > the kernel could read the brain of the adminstrator then you would be
> > happy, there is no way the kernel can know which is the task you really
> > want to have killed first.
> 
> I agree. On a server the most likely application to be killed would be the service with the most pages in memory. And those services tend to be the important ones.
> 
> However, for a simple desktop-linux that statistical approach seems to
> be wrong. Your vm has even killed /sbin/getty sometimes, so that I
> can't login via a simple console.

I see this problem, for most desktop users the biggest task plus some
other random bit like the nicelevel and length of runtime etc.. actually
result in a reasonable estimate of the best task to kill.

> Re-enabling the oom-killer gives a good result for me:
> 
> Dec  6 09:46:19 adlib kernel: Out of Memory: Killed process 643 (khexedit).
> Dec  6 09:48:42 adlib kernel: Out of Memory: Killed process 645 (khexedit).
> 
> What I complain is that your vm kills some processes without
> mentioning in the logs. How can I determine what processes the kernel
> has killed ?

no this is is not the case. It is always mentioned in the logs. Grep for
VM and you'll find all of them, no difference from before. I agree it
would be very bad if the admin couldn't know what was killed exactly to
restart everything properly (with the bad app under rlimit the next time ;)

> I hope that fairly simple patch does things right for all people that
> want the old behaviour. It's already a year ago I last hacked on the
> kernel.
> 
> diff -rauN linux-2.4.23/include/linux/sched.h linux-2.4.23-kp1/include/linux/sched.h
> --- linux-2.4.23/include/linux/sched.h  Fri Nov 28 19:26:21 2003
> +++ linux-2.4.23-kp1/include/linux/sched.h      Sat Dec  6 09:57:04 2003
> @@ -429,6 +429,7 @@
>  #define PF_DUMPCORE    0x00000200      /* dumped core */
>  #define PF_SIGNALED    0x00000400      /* killed by a signal */
>  #define PF_MEMALLOC    0x00000800      /* Allocating memory */
> +#define PF_MEMDIE      0x00001000      /* Killed for out-of-memory */
>  #define PF_FREE_PAGES  0x00002000      /* per process page freeing */
>  #define PF_NOIO                0x00004000      /* avoid generating further I/O */
>  
> diff -rauN linux-2.4.23/mm/oom_kill.c linux-2.4.23-kp1/mm/oom_kill.c
> --- linux-2.4.23/mm/oom_kill.c  Fri Nov 28 19:26:21 2003
> +++ linux-2.4.23-kp1/mm/oom_kill.c      Fri Dec  5 20:31:39 2003
> @@ -21,8 +21,6 @@
>  #include <linux/swapctl.h>
>  #include <linux/timex.h>
>  
> -#if 0          /* Nothing in this file is used */
> -
>  /* #define DEBUG */
>  
>  /**
> @@ -257,5 +255,3 @@
>         first = now;
>         count = 0;
>  }
> -
> -#endif /* Unused file */
> diff -rauN linux-2.4.23/mm/vmscan.c linux-2.4.23-kp1/mm/vmscan.c
> --- linux-2.4.23/mm/vmscan.c    Fri Nov 28 19:26:21 2003
> +++ linux-2.4.23-kp1/mm/vmscan.c        Sat Dec  6 10:21:55 2003
> @@ -649,13 +649,7 @@
>                                 failed_swapout = !swap_out(classzone);
>                 } while (--tries);
>  
> -       if (likely(current->pid != 1))
> -               break;
> -       if (!check_classzone_need_balance(classzone))
> -               break;
> -
> -       __set_current_state(TASK_RUNNING);
> -       yield();
> +       out_of_memory();
>         }
>  
>         return 0;

this should go back to the 2.4.22 deadlock prone oom killer yes. you can
also leave the yield() in the main loop (after out_of_memory())
(__set_current_state(TASK_RUNNING) isn't needed these days just yield is
safe enough).