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/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:30 EST