On Sun, 19 Mar 2000 14:48:17 -0500, you wrote:
> From: James Sutherland <jas88@cam.ac.uk>
> Date: Sun, 19 Mar 2000 18:46:05 +0000
>
> >Unless of course you are actually interested in tracking down and maybe
> >even fixing whatever memory leak may be causing the problem. In that
> >case, no joke, you really do want that problem to show itself reliably.
>
> It isn't a problem that CAN show reliably, if it is OOM related.
> (Arguably, it isn't even a problem.) Your code is using memory in a
> particular way; if there isn't any memory, it fails.
> Causing this particular (valid, AFAICS) use of memory to be a problem
> in itself would prevent the symptom above showing - but do you really
> want or need that?
>Yes.
>
>If the OOM condition is due to a memory leak, then memory overcommit
>hides the leak and thus makes it more difficult to fix.
>
>If the OOM condition is due to the fact that you've underestimated your
>system's vm needs, memory overcommit makes it more difficult to judge
>what the correct amount of vm in your system should be to ensure stability.
No - it means that the in-memory size of your image reflects your USE
of memory, rather than the amount you requested.
Overcommit can ELIMINATE one type of memory leak (just calling
malloc() and never using the returned block) - and doesn't really
affect any other use.
If you request, then use, a block of memory, overcommit never really
comes into play.
James.
-
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 : Thu Mar 23 2000 - 21:00:27 EST