Today, Mike A. Harris gleaned this insight:
> Process A which has went into lala land and is spinning out of
> control keeps allocating memory. It fills all of memory, and
> then all of a sudden a DIFFERENT process - say Netscape, needs a
> half a meg. The overcommit would give netscape the memory, but
> then when netscape USES it, the pages cannot be mapped, and the
> kernel kills Netscape, meanwhile it was Process A which caused
> the OOM condition 'logically'. That is the problem I believe, is
> that the kernel needs to try and determine using logic which
> process is the REAL bad guy. Next to impossible...
Yeah I get it now. Though based on my (admittedly limited)
understanding of the way the kernel currently decides to kill processes,
that doesn't seem like it's any _worse_ a scenario, just not any better.
> I'm dreaming up a daemon written in C for speed that:
>
> 1) Reads a config file of legal possible swapfile locations and
> min/max sizes it can use, etc..
> 2) Has configurable high/low watermarks to determine when to
> create new swap space.
> 3) Can monitor memory/swap usage on the fly every X number of
> seconds (configurable), and if swap usage hits a certain high
> water mark, the daemon can check disk space in the legal places
> set forth by the config file, determine which (if any) locations
> have enough space to create a swap file, and then creates a swap
> file or files as quickly as possible (with nice -20) - possibly
> even suspending other processes (configurable), then enables the
> new swap file to handle the situation.
I can see why this might make sense in some cases, but I don't think it
really solves the problem. If you OOM because of a badly behaved program,
or a malicous user's program, you're still going to have the same problem,
and much less disk space.
Based on what others have said in this thread, it sounds to me like the
right answer is for the kernel to do something like keep track of how fast
each process is allocating/using memory, and kill the highest users. And
it also sounds like that's in the works. So I'll shut up now... :)
-- --------------------------------------------------------------- Derek D. Martin | Unix/Linux Geek ddm@MissionCriticalLinux.com | derek@cerberus.ne.mediaone.net ---------------------------------------------------------------- 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/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:21 EST