Messages in this thread | | | From | James Sutherland <> | Subject | Re: Overcommitable memory?? | Date | Mon, 20 Mar 2000 20:08:09 +0000 |
| |
On 19 Mar 2000 2:9:9 +0100, you wrote:
>Den 17-Mar-00 00:55:01 skrev James Sutherland følgende om "Re: Overcommitable memory??": > >> Yes... So if you disabled overcommit, AND used a malloc wrapper which >> touches every page when it is allocated, you could guarantee the memory >> you had been "allocated" was REALLY allocated. > > When you say "disabled overcommit", are you referring to the current >implementation of /proc/sys/vm/overcommit_memory set to zero? If so, you >are right, except that an OOM killer can still select your process to be >the one to kill. I.e. you could have saved your trouble. Worse yet, you >could cause another process to be killed because you touch the pages.
Yes, if you are out of memory, something dies as a result. It's too late to avoid that by the time the OOM killer kicks in protecting more important processes.
> If you're talking about a working option to disable overcommitment of >memory, then: > > 1. If you don't overcommit, there is no need to touch the pages and no > gain from doing so. Touching the pages disables overcommit in itself. > 2. If you do overcommit, touching the pages won't protect you from an > OOM killer. Nor will it protect you from kill -9 or any other "You are hogging resources, so ... off" measure. Only using the right system for the job (i.e. one with the resources you need) will avoid problems.
>> Anyway, this all has nothing to do with the original topic, which related >> to how to handle out-of-memory situations - i.e. once all the memory has >> been allocated, however you allocate it. > > Only one thing: If you don't overcommit memory, the kernel will never >need to use an OOM killer.
Yes it will. You can still run out of memory. In fact, you will do so sooner without overcommit.
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/
| |