On 19 Mar 2000 2:49:12 +0100, you wrote:
>Den 17-Mar-00 09:24:31 skrev James Sutherland følgende om "Re: Overcommitable memory??":
>
>> malloc() CAN be overcommitted. If you set a VM flag via /proc, then
>> malloc() will *ALWAYS* succeed, even if there isn't any memory available
>> at all. With the flag clear, malloc() does some sanity checking before
>> granting the memory.
>
>> You CAN obtain an overcommit free malloc() by clearing the VM flag (it is
>> clear by default), then touching every page you allocate when you allocate
>> it.
>
> That's all theory. Reality is that Linux always overcommits memory
>regardless of what you set /proc/sys/vm/overcommit_memory to. Proof:
(snip sample program which does NOT touch the allocated memory)
> I started 14 processes which each successfully allocated 64 MB. That's
>14 * 64 MB = 896. The box just doesn't have that kind of RAM+swap. The
>overcommit flag is off, but the allocations still succeeded, even though
>they shouldn't have. If my memeater program had actually touched all that
>memory, I would probably have been on my way down into the basement now to
>reach for the reset button to bring the system back up again. Uptime says
>11 days, so it would have fallen into the normal 10-15 day OOM crash
>interval. If only overcommitment could be disabled...
How would this help? You would just allocate the memory you have
faster, and run out of memory sooner.
Anyway - your system crashes to a "big red switch" state when a
process grabs all the VM?!?! You have a serious problem there - but it
isn't overcommit. Which process is leaking, anyway??
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