Messages in this thread | | | From | James Sutherland <> | Subject | Re: Overcommitable memory?? | Date | Sun, 19 Mar 2000 18:55:47 +0000 |
| |
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/
| |