Messages in this thread | | | Date | Thu, 13 Jul 2000 16:18:59 -0300 (BRST) | From | Rik van Riel <> | Subject | Re: OOM in 2.2.14 |
| |
On 13 Jul 2000 jmcmullan@linuxcare.com wrote: > Rik van Riel <riel@conectiva.com.br> wrote:
> >> Would take a lot of the OOM cruft out of the kernel, and > >> would alloe pop-up messages, selectable kill-this-app dialogs, > >> AI systems, whatever. > > > This is lunacy. If we're out of memory, how can we allocate > > the memory to do a pop-up message? And where should that > > menu appear? On what console of which user? What if we're > > a webserver at 4 AM? > > A root-owned daemon that has made sure to lock down > any memory it may need via mlock() won't have any swapping > issues. Running at nice -20, or even better, FIFO scheduling, > you can eat as much (or as little) of a timeslice from other > apps as needed.
That will: - cause you to always have a program mlock()ed in memory, taking up more space than a simple kernel subroutine - result in an OOM killer which has less information available than an in-kernel OOM killing routine (how are you going to read stuff from /proc when you're OOM?) - still not give you the "pop-up window" since you haven't reserved memory for the X server and window manager to be able to display that window in the first place ;)
> Actually, extending klogd to have a pluggable > log-message-to-action filter would be the best general case > solution. Then, you could handle missing floppies, automatic > Ooops handling, whatever.
This is a completely separate issue, but a really neat idea. However, this is not something that will be able to run when the system has no more memory left ;)
> Your thoughts?
You have some very nice ideas, but none of them will be able to run when the system is out of memory. Maybe you want to take the "we're out of memory" constraint into consideration when designing an OOM handler...
regards,
Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000
http://www.conectiva.com/ http://www.surriel.com/
- 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/
| |