Messages in this thread | | | Date | Tue, 9 Dec 2003 15:21:51 +0100 | From | Andrea Arcangeli <> | Subject | Re: oom killer in 2.4.23 |
| |
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). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |