Messages in this thread | | | From | James Sutherland <> | Subject | Re: Overcommitable memory?? | Date | Tue, 21 Mar 2000 12:10:53 +0000 |
| |
On Mon, 20 Mar 2000 21:47:26 -0600, you wrote: >On Mon, 20 Mar 2000, David Whysong wrote: >>On Mon, 20 Mar 2000, James Sutherland wrote: >>>On Mon, 20 Mar 2000 05:39:48 -0600, you wrote: >>>>On Sun, 19 Mar 2000, David Whysong wrote: >>> >>>Just send SIGTERM. This gives them an opportunity to exit gracefully. >>>If they ignore it, SIGKILL them. >>> >>>>>Once we are OOM, you can't give user-space any choices. >>>> >>>>YOU ARN'T OOM - a specific user is out of resources, not a catastrophic >>>>failure. >> >>A user being out of (memory) resources shares many of the same problems of >>a system that is OOM. You still need to kill one or more user processes, >>and you can't give the user the choice, because the user might decide to >>keep on running. > >The user process (one of them) has been aborted. As long as the user >remains below the limit, the user can keep on running.
This is what happens when the system is OOM, too. No advantage there.
>>>SOMETHING (the user, the process, the system, the cluster, whatever) >>>is out of resources, so something has to give. Which unit has run out >>>of resources doesn't matter - the issue is how we handle running out >>>of resources in some category. >> >>Precisely. >> >>>>>I don't like resource limits. Using resource limits is similar to not >>>>>having memory overcommit -- you waste a lot of system resources "just in >>>>>case", the kernel needs to do a lot more accounting, and it's just >>>>>horribly inefficient. >>>> >>>>Resource limits CAN prevent the OOM condition if >>>> 1. the sum of all concurrent users is <= total resources >>>> 2. users are not allowed to exceed their quota >>> >>>That's an extremely restrictive approach, but appropriate in some >>>cases. We need those resource limits - but what's this got to do with >>>overcommit?? >> >>Preventing system OOM using resource limits is equivalent to disabling >>overcommit. You have to restrict each of N users to 1/N of the total >>system memory. > >NO. Different users can have different limits. The total of the concurrent >users must not exceed the amount of the resources. If it is decided to do >so then you are overcommiting the resource,
Be careful; this is a TOTALLY different use of "overcommitting" than we are using in this thread.
> which may be valid in many >cases (single user workstations are one, but there you may not want to >enable quotas anyway). > >1/N is the worst way to set quotas. It is one way to divide a users >quota over his process group, but I'm not exactly in favor of that either. > >1. Determine how large the individual processes have to be to work. Use > the worst case processes. >2. Determine how many users use the worst case process at the same time. >3. Determine how many users can run at the same time. > >This cycle is done repeatedly to identify time intervals, attended vs >unattended operation. Then a proposed scheduling policy that allows >the best mix of operations that is acceptable to the user community. > >This may call for running large processes at night - with few interactive >users. It may allow for many interactive users during the day, but none >of them may be able to run the worst case process then (it may take the >entire system for the process + its parent shell and the rest of the >system processes. NO OTHER USERS. > >What ever is finally decided by the the users and management. It should >not be dictated by the OS.
True.
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/
| |