| |||||||||||||
Another OOM killer rewriteAnother OOM killer rewritePosted Jun 20, 2010 20:15 UTC (Sun) by nix (subscriber, #2304)In reply to: Another OOM killer rewrite by Zizzle Parent article: Another OOM killer rewrite
a OOM killer that pops up a little GUIYeah, but doing that while avoiding (or absolutely minimising) memory allocations, that's hard.
(Log in to post comments)
Another OOM killer rewrite: GUI pop-up Posted Aug 19, 2010 20:18 UTC (Thu) by AnswerGuy (guest, #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.
|
|||||||||||||