User: Password:
Subscribe / Log in / New account

Stopping unwanted OOM killer experiences

Stopping unwanted OOM killer experiences

Posted Nov 18, 2004 21:09 UTC (Thu) by tkreagan (subscriber, #4548)
In reply to: Stopping unwanted OOM killer experiences by rwmj
Parent article: Stopping unwanted OOM killer experiences

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?

(Log in to post comments)

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.

Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds