Messages in this thread | | | Date | Mon, 17 Jul 2000 18:03:29 -0700 | From | Mike Touloumtzis <> | Subject | Re: OOM in 2.2.14 |
| |
On Fri, Jul 14, 2000 at 12:01:05PM -0300, Rik van Riel wrote: > On 13 Jul 2000 jmcmullan@linuxcare.com wrote: > > > That is yet another alternative. The point is to put all > > of the process killing logic in user-land - not to quibble about > > possible implementations of such logic. > > So you didn't read my last replies to your email at all? > > When we're OUT OF MEMORY, there is NO MEMORY LEFT to even get > information from /proc. Well, in some cases there may be memory > left, but in other cases there isn't so you can't operate on > that assumption. > > Let me repeat myself: NO MEMORY LEFT. NADA. ZILCH. NOTHING. > > In that case no userspace "solution" will be able to get the > relevant info from /proc and make a sane choice as to which > process to kill. That is why an OOM killer has to be in the > kernel (which, incidentally, is where my OOM killer patch runs). >
I've taken a (non-totally-careful) look at the page fault handler and return from syscall paths with user-space OOM handling in mind, at it looks to me like you could, in fact, implement a userspace handler, using an approach something like this:
-- daemon uses mlockall(MCL_CURRENT|MCL_FUTURE) -- daemon holds /dev/oom open, runs using RT priority, but sleeps most of the time. -- kernel pages for mmap() of /dev/oom are allocated at device open time or a similarly non-critical time. -- page fault handler invokes something that will write a summary of process info to mmapped pages and wake userspace daemon. it keeps track of the number of times the userspace daemon is woken within a single OOM condition (mechanism TBD). -- daemon will kill processes according to a user-defined algorithm, with increasing aggression each time it is woken. -- if the daemon doesn't alleviate the situation after N tries, kernel resorts to current behavior (do_exit(SIGKILL) on process in page fault handler).
This relies on the ability to kill another process and reclaim its pages without allocating memory; I don't know for sure if this works, but at a quick glance, at least kill_proc() appears to be OK.
The use of a fixed-size set of kernel pages means that the full breadth of /proc info won't be available, but this approach could work nicely for common cases like:
if (!strcmp(s, "navigator") || !strcmp(s, "mozilla-bin")) kill_bloated_hog();
Of course, it's probably much less complex to do the same thing in a loadable kernel module. But I don't think the userspace option should be dismissed out of hand without a statement to the effect of "it is impossible to return control to a userspace mlockall() daemon because X function uses get_free_page()." There may be such a problem, but so far I haven't seen it cited.
miket
- 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/
| |