Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

Stopping unwanted OOM killer experiences

Posted Nov 18, 2004 11:12 UTC (Thu) by rwmj (subscriber, #5474)
Parent article: Stopping unwanted OOM killer experiences

I've been hit by the OOM killer recently too.

There seems to be a simple and obvious fix: allow the user to specify a list of processes and a priority for each. The OOM killer would kill low-priority processes first.

On my system, the list would look something like this:

10 X                    # killing X should be a final resort
 8 firefox-bin          # don't have session management
 6 apache               # development server, doesn't matter if it is killed
 4 wineserver           # generally running IE, so unimportant
 2 gaim, ical, xpostit  # no state, doesn't matter if killed
 0 artsd, esd, kdeinit  # I try to kill these regularly anyway, but they
                        # still manage to pop up somehow

Rich.

(Log in to post comments)

Stopping unwanted OOM killer experiences

Posted Nov 18, 2004 21:09 UTC (Thu) by tkreagan (subscriber, #4548) [Link]

Doesn't it strike anyone as a little crazy the way kernel development keeps getting backed into more and more special cases? It seems like things are turning into an unworkable mess, with OOM killers tripping over thrash-swappers tripping over pluggable schedulers, two separate volume management solutions, and an endless number of constantly changing kernel data structures.

I realize that there are significant benefits to letting the kernel evolve on its own, but am I the only one who thinks its time to focus on pruning, bug fixes, and validating existing structures before we take off on the next flight?

Or have I spent too much time in the OpenBSD world?

Stopping unwanted OOM killer experiences

Posted Nov 27, 2004 16:56 UTC (Sat) by riel (subscriber, #3142) [Link]

Alternatively, you might not have spent enough time looking at the OpenBSD VM, which has its own share of special cases ;)

Every VM I've seen (and yes, I have looked at all the BSDs, XNU, Mach and others) are chock full of special case handling. Take a look at vm/vm_glue.c next time you're in FreeBSD land...

Yes, the swap token thrashing prevention code has a few corner cases, but it doesn't require anywhere near the number of magic constants that traditional Unix and BSD memory scheduling algorithms require.

Stopping unwanted OOM killer experiences

Posted Nov 19, 2004 21:18 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

I sure hate to see people working on tuning the OOM killer, as if it's a normal part of memory management. The OOM killer is just a less drastic form of panic. When it runs, the system is broken. There are even cases where a panic would be better.

I understand that it's very difficult to get memory management right, and as a band-aid, the OOM killer can be better than a reboot in the same way that an oops is often more convenient than a full panic.

The OOM killer should never run when there are pageouts in progress. I don't care how slow they are. If the pageout device is broken and the pageout is actually indefinite, that should be handled like any pageout I/O error. If things are just slow, a user space process that monitors performance and kills some processes to speed up others would be appropriate. The kernel should kill processes only when it is backed into a kernel-level corner, like where it doesn't have enough swap space to back the virtual memory it has created and is thus deadlocked. And users ought at least to have the option of allocating resources so the kernel doesn't get deadlocked.