lkml.org 
[lkml]   [2000]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.723 / U:0.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site