lkml.org 
[lkml]   [2000]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Avoiding OOM on overcommit...?
On Tue, 21 Mar 2000, Jesse Pollard wrote:
>David Whysong <dwhysong@physics.ucsb.edu>:
>>
>> 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.

Good point. That's true... (can you tell there's a BUT coming?)

BUT, You agree below that quotas cause failures to occur earlier (from a
user's point of view). So it's possible to have a quota system killing
processes when otherwise everything would be running happily.

You want quotas. I prefer Rik's OOM killer patch plus a daemon. Sure, my
situation still has OOM conditions, but they're handled. The daemon can
implement a close approximation to your quotas, entirely in user space.
And it can be very flexible.

>> 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.

Sorry, but I think you're wrong. The system will crash or reboot only if
it is broken (Linux is broken in this respect the last time I checked).
And I think we have already established that on large multi-user systems,
overcommit makes the system much more usable for a fixed amount of
resources. Read on:

>non-overcommit:
> 1. aborts at least one user process
> 2. may abort multiple processes, but all belonging to the user over quota
>
>overcommit:
> 1. aborts at least one user process

Not always! In cases where the non-overcommit scheme has to abort a
process, we may not have to because of COW page sharing, etc.

> 2. may abort multiple processes belonging to different users

This has nothing to do with memory overcommit. It's a function of your OOM
(or OOR) handling policy. That's why I want to move the OOM killer policy
to user-space.

> 3. may abort system processes
> 4. may force reboot.

Neither 3 or 4 should ever occur, unless the system is broken. Again this
should have nothing to do with memory overcommit.

>> 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.

You agree with me? Now I'm confused. :-)

Dave

David Whysong dwhysong@physics.ucsb.edu
Astrophysics graduate student University of California, Santa Barbara
My public PGP keys are on my web page - http://www.physics.ucsb.edu/~dwhysong
DSS PGP Key 0x903F5BD6 : FE78 91FE 4508 106F 7C88 1706 B792 6995 903F 5BD6
D-H PGP key 0x5DAB0F91 : BC33 0F36 FCCD E72C 441F 663A 72ED 7FB7 5DAB 0F91


-
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.063 / U:0.256 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site