Hi David.
>> The basic problem as I understand it is not the memory
>> allocated by applications, but the memory allocated by the
>> kernel AFTER the various applications have grabbed theirs.
>> In particular, this is memory used for the buffer cache,
>> the networking stack, the system stack, and the like.
> No. Application dynamic memory is the problem, in addition
> to the kernel memory allocation.
In other words, all the arguments presented so far by both sides
of this argument have been way off field? Somehow, that doesnae
surprise me.
>> As I understand the arguments presented so far, they can be
>> summarised like this:
>> 1. The anti-overcommit brigade:
>>
>> No matter how much memory is used by applications when the
>> kernel is running, if the kernel requires more memory for
>> some essential task (such as the system stack) than is
>> available, we let the system crash by denying that memory
>> to the kernel.
> The system crash issue is completely separate from memory
> overcommit. The fact that you can crash Linux by running
> OOM is a kernel bug. The best anti-overcommit argument I've
> seen is that programs shouldn't be killed just because
> somebody else called malloc() too much.
The commonest anti-overcommit argument I've seen is that the
program that called malloc() too much shouldn't get killed
either, and that doesn't make sense to me.
> I don't agree with this, because I think the problem isn't
> really due to memory overcommit -- it's a problem with
> handling OOM situations, which can occur with or without
> overcommit.
That summarises my take on the underlying situation as well.
> The problem can be solved using quotas and guaranteeing
> some memory to each user. I REALLY don't like quotas
> myself, but I see why others want them.
I'm not fond of them either, but one needs to have them unless
one can safely assume that there are no idiots around who will
try to break into one's system...
> The anti-overcommit people claim this is better because
> malloc() can return NULL. As Alan pointed out, the problem
> with this argument is that there are other implicit ways
> that programs can use memory, and you can't easily notify
> the users program that they can't, for example, allocate
> another variable on the stack.
I believe Alan also pointed out that if application programs have
used all memory in a non-overcommit scenario and something causes
the kernel to want to either page in a swapped out buffer or load
some module so that it can report this fact, there are serious
problems.
>> 2. The pro-overcommit brigade:
>>
>> No matter whether a program really needs the 300M of memory
>> it's just asked for, we will tell the program we can give
>> it that memory, and then have the program crash when it
>> validly assumes we've told the truth.
> Partly right. But the real reason for overcommit is
> practical: you can do more with overcommitted memory, and
> there are no additional failure modes.
> If we define "failure" as a situation where a user program
> must be killed because we are out of memory, then
> non-overcommit systems should always fail more often than
> overcommitted ones. So I don't see any downside, AT ALL, to
> memory overcommit.
Personally, I've had no problems that I could place as being due
to overcommitted memory, so I intend to follow the advice not to
fix something that isn't broken.
Best wishes from Riley.
* Copyright (C) 2000, Memory Alpha Systems.
* All rights and wrongs reserved.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* http://www.memalpha.cx/Linux/Kernel/
-
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 : Fri Mar 31 2000 - 21:00:15 EST