>
>
>>The kernel allocates memory within itself. We will still reach OOM
>>conditions. It can't be avoided.
>>
>
>That doesn't sound good.
>
>What bugs me about this statement was that until 2.4, I never had
>lockups. I sometimes had a LOT of swapping and slow response, but I
>also knew that running a complex numeric simulation when RAM <
>'program needs' does that. I accepted it and tended to arrange such
>runs in my absence. Now I find that I get some process nuked (or
>worse - partially nuked) even after increasing to 4x swap and
>eliminating lazy habits that would leave some idle process up for a
>few days in case I needed it again (worked fine in 2.0.36). There are
>_alot_ of good things in 2.4, but sometimes....
>
>
>Does your statement imply that a machine left "alone" must eventually
>OOM given enough runtime?? It seems that it must.
>
Nope, not at all. The kernel acquires and releases memory as it goes.
My statement is to the fact that we can reach a point where we have
exhausted all the memory resources by the time we start a particular
code path but in order to complete that code path we need more memory.
I.e. journaled filesystems. We have reached 0 memory but we need to
start down a code path to update data on the disk. That means we may
have to allocate memory to read and update the journal as we start
writing regular file data to disk.
This only occurs when we ride right on the very edge of OOM. This will
also be fixed when we implement all the desired bean counting.
David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 23 2001 - 21:00:25 EST