On Mon, 20 Mar 2000 14:49:44 -0800 (PST), you 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.
Equally, HOW does the user see that choice - bearing in mind all their
processes may be suspended? Do you try to guarantee their shell can
display and respond to some kind of prompt without allocating any
memory or stack space? How do you know the user is even logged in?
Finally, what choice do you give them - "Please enter the PID of the
process you want killed"?
(snip)
>>>>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. That is NOT overcommit. Overcommit, in this context, is when a
process calls malloc() and is given unpopulated address space, which
will be populated on use.
This does not affect overcommit at all. What it DOES do is restrict
OOM conditions to individual users, rather than systemwide - but at
the expense of massive restrictions on what the users can do.
Completely impractical for most environments - OK, it makes your job
easier (you don't have to deal with runaway processes etc.) - but it
will probably cost you that job anyway, when they find out you have
hindered use of the facility so seriously.
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:32 EST