Messages in this thread | | | Date | Fri, 03 Sep 1999 15:44:24 +0200 | From | Helge Hafting <> | Subject | Program Killers, beancounters, etcetera [Regarding linux memory DOS thread] |
| |
> Hello, > I don't mean to butt in, but I must interject on the kernel-based > program killer changes that people are talking about. Currently, the > program killer that Linux has is simple and brutal. Although it's not > very accurate, it gets the job done. I am not saying that there is no > better solution, I just think that a userspace tool could perform the > more complicated emergency memory management algorithms. A program could
The big problem here is that when you run out of memory you can't necessarily swap in that userspace program. Even an often-polling program may be swapped out or dropped from memory shortly before OOM. You could modify the kernel to give your OOM killer preferential treatment - but you might as well put the program in the kernel in that case, because you are: 1) modifying the kernel anyway 2) Keeping the OOM killer in memory all the time - i.e. memory consumption as bad as a "bloated" kernel containing the OOM killer.
> poll /proc every few milliseconds (overhead would be minimal) and if it > detects a problem (say memory usage going above a certain percent) it
Why poll - the kernel knows *precisely* when it runs out of memory. If we want a userspace program for that, create a device that blocks until OOM and have the userspace program read from that device. But I don't think you can run it - it will probably be swapped out by OOM time.
Another problem is that the kernal will OOM *between* your polls. What should it do in the meantime? It could try to schedule other programs, not knowing which one is the OOM killer. And most scheduling attempts would probably just hit OOM again as the programs are swapped out already.
> would perform whatever it is designed to do (I don't want to start > rehashing all the ideas everyone has had, so I'll just say the > advantages of implementing it in user-space: [some reasons deleted]
> 3: A running program could be replaced with a different one on the fly > without having to reboot or recompile the kernel. A module for OOM-handling is equally on-the-fly-replaceable.
Helge Hafting
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |