Messages in this thread | | | Date | Tue, 21 Mar 2000 11:18:04 -0800 (PST) | From | David Whysong <> | Subject | Re: 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/
| |