http://lwn.net/Articles/111408/ This is a special feed containing comments posted to the individual LWN article titled "Stopping unwanted OOM killer experiences". hourly 2 http://lwn.net/Articles/113001/rss 2004-11-27T16:56:35+00:00 riel Alternatively, you might not have spent enough time looking at the OpenBSD VM, which has its own share of special cases ;)<br> <p> 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...<br> <p> 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.<br> http://lwn.net/Articles/112807/rss 2004-11-25T11:35:01+00:00 cross <font class="QuotedText">&gt; The patch appears to have solved the problems without taking away the benefits of the token-based approach.</font><br> <p> Err actually it hasn't, though it is an improvement. The most recent tree without these OOM problems remains 2.6.8.1<br> <p> http://lwn.net/Articles/111904/rss 2004-11-19T21:18:43+00:00 giraffedata 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. <p> 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. <p> The OOM killer should <em>never</em> 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. http://lwn.net/Articles/111749/rss 2004-11-18T21:09:00+00:00 tkreagan 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.<br> <p> 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?<br> <p> Or have I spent too much time in the OpenBSD world?<br> http://lwn.net/Articles/111569/rss 2004-11-18T11:12:52+00:00 rwmj I've been hit by the OOM killer recently too.<p> 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.<p> On my system, the list would look something like this:<p> <pre> 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 </pre> Rich.