lkml.org 
[lkml]   [2000]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Overcomittable memory
Date
On 21 Mar 2000 15:3:42 +0100, you wrote:

>Den 20-Mar-00 21:04:35 skrev James Sutherland følgende om "Re: Overcomittable memory":
>> On Mon, 20 Mar 2000 19:04:06 +0000, you wrote:
>
>>>I've seen this happen on several PCs, where all you do is malloc lots of
>>>memory and fill it. It'll hard lock after a while. Yes, it's a bug,
>>>but...
>
>> So fix the bug, don't change the system to avoid showing it!
>
> The system _is_ the bug. Please tell me what is wrong with allocating a
>piece of memory and using it? Nothing, of course. Yet Linux will currently
>nuke the process (or another completely unrelated process) for doing that.

There is very definitely something wrong with trying to take memory
which doesn't exist.

>> Disabling overcommit just means your process grabs more memory
>> earlier.
>
> It does not. Disabling overcommit means that when a process can't get
>memory, it is told that it can't get memory.

Yes. In other words, a random process gets an error due to another
process, and (typically) dies as a result. Not good.

>>>4) Main loop, never allocate any memory during runtime. Use the 512MB as
>>>a heap. Or better yet, don't do any dynamic allocation. In fact, don't
>>>do any syscalls at all. Run here for a few weeks...
>
>> Just run for a few weeks without logging or journalling anything. Hrm.
>> Bright design. Supposing there is a power failure or system crash
>> during this time?
>
> Power failures, system crashes, etc. is not the issue. You're claiming
>that the kernel can have a good reason to kill that program. Please
>explain. Trust me, neither the user nor the programmer will agree with you.
>They have standards documents to back them up.

Find me a standards document which says "Don't kill processes to free
up resources in an emergency - just let the system collapse."

>> If you want non-overcommitted memory, just touch it on allocation.
>> That's it. No need to mangle the kernel or anything else.
>
> Touching the allocated pages does not help even the slightest bit. Take
>Rik's OOM patch as an example. Your process can touch its memory as much as
>it wants, but it will not protect it from Rik's OOM killer.

Of course not. If your process is hogging resources, causing problems,
I fully expect it to be killed. Do you just leave giant core files in
your root partition taking up all the space, or do you remove them
when you run out of space and processes start dying because of it?


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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.140 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site