> >> 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 neatidea. However, this is not something that will be ableto run when the system has no more memory left ;)

> Your thoughts?

You have some very nice ideas, but none of them will beable to run when the system is out of memory. Maybe youwant to take the "we're out of memory" constraint intoconsideration when designing an OOM handler...