On 21 Mar 2000 11:29:58 +0100, Jesse Pollard <pollard@cats-chateau.net> wrote:
>On Sun, 19 Mar 2000, David Whysong wrote:
>>Repeat after me:
>> You can not solve the OOM problem in user space.
>> You can not solve the OOM problem without killing processes.
>> Resource limits are not a good solution to the OOM problem.
>>
>>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
No, they can't. Users are just one of the OOM causes. Imagine that no users
allocate memory at this time (only have what they have allocated before).
and then say syslog(8) wants to allocate memory, but there is no more. Or
its stack just happens to grow and needs another page to allocate. Who do
you kill ? syslog, which tried to use memory when there is no more (actually
there is, but because of your no-overcommit policy it may not access it) ?
Sysadmin, which did not anticipate that spare 100MB (after all users are
withing their full limits) of memory would not be enough when some rare
condition cases all system daemons to ask for some more memory ? Or do you
also put VM quotas on root ? (which will kill some really old process, like
init. Or sshd so sysadmin cannot login to fix problem)
Or, as another example, quite a few TCP packets come in when system was low
on memory (but all users maxing their per-user VM quotas) and system needs
to allocate more network buffers. Who do you kill ? kernel, since it tried
to allocate more memory ?
Or VM tries to allocate disk buffers ? there are quite a few reasons for
system to hit OOM even where there are ZERO user processes running at all,
much less using too much memory.
When that happens (and it will happen), you can kill some root owned process
and try to continue, or you can panic. In first case, MAYBE system is as
good as dead (if you killed process critical for system operation). In
second, system is CERTAINLY dead. I prefer first case.
When it hits OOM, kernel will start killing things. What I would prefer (and
what I would code, if I needed it, which I don't at this time) is syscall
which enables sysadmin to define order by which processes will be shot when
time comes for this (see my previous post)
-- Opinions above are GNU-copylefted.- 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:37 EST