On Sun, 19 Mar 2000 14:39:31 -0600, you wrote:
>On Sun, 19 Mar 2000, James Sutherland wrote:
>>On Sat, 18 Mar 2000 12:45:35 -0600, you wrote:
>>
>>>On Fri, Mar 17, 2000 at 10:10:23AM +0000, James Sutherland wrote:
>>>> Yes, you COULD have COW without overcommitting - but you still lose one of
>>>> the major benefits of COW, namely huge savings on VM usage. If I fork()
>>>> 100 Apache processes of 20Mb each, I need perhaps 30Mb of VM total.
>>>> WITHOUT overcommitted COW, I end up needing 2Gb of swap space - 1.98Gb of
>>>> which I will never use! This is certainly not an efficient use of swap
>>>> space, IMO...
>>>
>>>This is why god gave us segments. Can share the code; just have room for
>>>the data.
>>>
>>>Actually, I suppose it would be possible to know how much is code not
>>>likely to change (runtime loadable modules), and not have to commit for
>>>that.
>>
>>Or just commit based on the memory which is really being used by the
>>process, which is nice and simple, and hasn't caused any problems I
>>know of yet.
>>
>>It works - why change it?
>
>Because it doesn't work. Systems crash. Systems do reboot. Reliability
>is just not there for production server capability.
When have you seen a Linux box crash simply because all the
application memory was in use? I have never seen this, and it
certainly shouldn't happen...
What is really happening is that a BUG in the kernel is
rebooting/crashing the system under particular circumstances. Fix that
bug, not the circumstances under which it shows up.
Disabling overcommit does NOT prevent the system running out of
memory. It exacerbates it.
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:29 EST