Messages in this thread | | | From | James Sutherland <> | Subject | Re: Overcomittable memory | Date | Tue, 21 Mar 2000 12:31:06 +0000 |
| |
On Tue, 21 Mar 2000 12:20:30 +0000, you wrote:
>James Sutherland wrote: >> On Mon, 20 Mar 2000 19:12:13 -0800 (PST), you wrote: >> >On Mon, 20 Mar 2000, James Sutherland wrote: >> >>On Mon, 20 Mar 2000 19:04:06 +0000, you wrote: >[...] >> >Currently there is no way to disable overcommit in Linux. >> >> True; to disable it completely, you would need to remove the dynamic >> stack expansion, giving every process a fixed-size stack. Another Gb >> or so of wasted swap, another few unexplained crashes... > >Where are you getting this from? The whole point of that nice example I >gave previously was that there were no reasons whatsoever that it could >die. None at all. Zip. Nadda. Please find one.
Whenever you use the stack, unless you were providing your own, fixed-size stack.
>Not to mention the program would be actively using the entire of its >allocated memory, so swap isn't exactly wasted.
If your process is actively using the space, it will never be affected by overcommit anyway.
> In fact, you now know >exactly how much memory+swap you need. In the example, it used 512MB. So >you'd need exactly (give or take a few pages) 512MB more RAM or swap >(preferably RAM). This would be exactly the same amount you'd need if >you ran it with overcommit turned on.
So overcommit doesn't cause any possible problems.
>The important difference is that other processes will not cause the big >512MB process to die. This is the behaviour I've been trying to >describe.
This has nothing to do withovercommit. Your process may be killed for a variety of reasons (system low on resources, hostile sysadmin, system reboot, etc.) but nothing to do with overcommit.
This is true whether overcommit is enabled or not.
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/
| |