User: Password:
|
|
Subscribe / Log in / New account

Another OOM killer rewrite

Another OOM killer rewrite

Posted Jun 17, 2010 16:24 UTC (Thu) by Zizzle (guest, #67739)
Parent article: Another OOM killer rewrite

In the age of Kernel Mode Setting, I was just thinking that the desktop distros should consider a OOM killer that pops up a little GUI that gives a chance to kill off an offender or two. Often the user has context and preferences that are quite dynamic.

Have the GUI timeout and default to the existing OOM code that the machine stays functional if the user is not around.

Or maybe something along the lines of GNOME's low disk space warning. A userspace monitor that either notices, or gets hints from the kernel that memory+swap is running low and pops up a window to allow clean shutdown of applications.

At the very least it would be great if the desktop distros could display a pop up or something letting the user know that the OOM killer has run, what it selected and why.

I'm wondering how many apps wrongly get the blame for crashing because they have been selected by the OOM.


(Log in to post comments)

Another OOM killer rewrite

Posted Jun 20, 2010 20:15 UTC (Sun) by nix (subscriber, #2304) [Link]

a OOM killer that pops up a little GUI
Yeah, but doing that while avoiding (or absolutely minimising) memory allocations, that's hard.

Another OOM killer rewrite: GUI pop-up

Posted Aug 19, 2010 20:18 UTC (Thu) by AnswerGuy (subscriber, #1256) [Link]

Clearly the way to avoid the memory shortage at the time that you're OOM is to pre-create the GUI dialog, pre-allocating all it's memory and then have it tied into some IPC (even an open FS on a named PIPE, a la /dev/initctl). Even a signal handler might work)

Then the OOM code simply posts an event to the IPC or sends the signal.

Now the GUI un-hides itself (this might trigger some memory utilization in the X server's backing store but that's very likely to already be available from X' heap and if any malloc() fails I'd hope that the X server would be robust enough to simply throw away the backing. Backing store is a caching feature that should fail gracefully).

The trick now is for the code filling in the GUI dialog to traverse the process table, displaying entries and allowing the selection of death all within the memory it pre-allocated. It must be prepared to page through the process listing in relatively small (let's say 4KB) fragments.

Another OOM killer rewrite: GUI pop-up

Posted Aug 21, 2010 19:37 UTC (Sat) by oak (guest, #2786) [Link]

That's way too fragile.

Use memory cgroups and their new OOM-kill handler/notifier and put the GUI, X and anything else the GUI program uses to a higher priority cgroup and anything you might want to kill to another cgroup.

Note that normal users don't know what all the (important!) background daemons are so the GUI should probably list for killing only the GUI processes which user has himself opened and which importance he knows.


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