On Tue, 21 Mar 2000 08:38:45 -0600 (CST), you wrote:
>David Whysong <dwhysong@physics.ucsb.edu>:
>> On Mon, 20 Mar 2000, Jesse Pollard wrote:
>>
>> >On Mon, 20 Mar 2000, David Whysong wrote:
>> >>
>> >>That's very misleading. In fact if you give the overcommitted system the
>> >>same amount of VM, it will work just fine.
>> >>
>> >>In other words, turning off overcommit isn't what saves you. You added
>> >>more memory!
>> >
>> >I guaranteed that the memory allocated could be used. I didn't just add
>> >more memory. Just adding more memory will still allow the system to fail,
>> >it may take longer, it may not happen as often. But it can still happen.
>>
>> The only reason your non-overcommit situation doesn't fail is because you
>> gave that system more memory than the overcommitted system.
>
>No. just adding more memory would still allow the OOM to occur. and possibly
>for the same reason. Runaway memory allocators are not stopped by adding
>memory. They are stopped by resource limits. I just want the ability to
>define that limit on a per-user basis so that I can prevent it from affecting
>other users.
>
>In a system that doesn't support resource quotas, just adding memory
>doesn't prevent the OOM. It just delays it. There is no control.
>
>> In order to make a reasonable comparison, you must keep the total VM
>> constant. The failure modes for a non-overcommitted system are a superset
>> of the failure modes of an overcommitted system.
>
>NOPE - it's a subset. The OOM condition affects many users, not one. It can
>affect the usability of the system. It can crash/reboot the system.
>
>non-overcommit:
> 1. aborts at least one user process
Yes.
> 2. may abort multiple processes, but all belonging to the user over quota
With user quotas, yes.
>overcommit:
> 1. aborts at least one user process
Yes.
> 2. may abort multiple processes belonging to different users
No.
> 3. may abort system processes
No.
> 4. may force reboot.
No.
Again, you are confusing overcommit and the absence of user quotas.
>> Stated another way: for a fixed quantity of virtual memory, in low memory
>> situations, a system without overcommit will ALWAYS have a failure before
>> or at the same point as an overcommitted system.
>
>yes.
So what advantage is there in disabling overcommit? You just get the
same failure more frequently and sooner.
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:35 EST