On Sun, 19 Mar 2000 19:59:33 -0800 (PST), you wrote:
>On 19 Mar 2000, Rask Ingemann Lambertsen wrote:
>>Den 16-Mar-00 20:18:09 David Whysong wrote:
>>> On 15 Mar 2000, Rask Ingemann Lambertsen wrote:
>>>>Den 14-Mar-00 18:32:49 Rik van Riel wrote:
>
>>>>> Not really. Without overcommit you may still have random program
>>>>> crashes and lost work...
>>>>
>>>> Yes, really. Maybe I should have said "additional lost work" instead
>>>>of just "lost work". Without overcommit, program crashes will only
>>>>happen due software bugs or hardware problems.
>> ^^^^^^^^^^^^^^^^^
>>
>>> Not true. With no overcommit, you can still crash programs due to OOM
>>> situations.
>>
>> Sure, not all programs are bug free. But that's a whole lot different
>>from having the kernel kill processes just because the kernel fails to
>>perform basic bookkeeping.
It is NOT "failing to perform basic bookkeeping". It is simply
deferring memory allocation until the memory is used.
>I said crash due to OOM, not due to bugs. I never said anything about bugs.
>
>You can't avoid memory overcommit without dealing with:
> 1. mmap()'ed data
> 2. stack growth
> 3. kernel dynamic memory allocation
>
>...and probably a host of other things I know nothing about. You're
>talking about adding a tremendous amount of overhead and complexity for no
>real benefit.
Yes. Disabling demand-allocation would cost you a LOT of
functionality.
>>> Memory overcommit is here to stay. As I recall, Linux already used
>>> overcommit and COW when I started using it at version 0.99pl13.
>>
>> So what is /proc/sys/vm/overcommit_memory for, if not to make
>>overcommitment of memory an _option_?
>
>It has already been shown on this list that
>
># echo 0 > /proc/sys/vm/overcommit_memory
>
>does not, in fact, disable memory overcommit.
You CAN, however, disable overcommit (i.e. deferred allocation of VM)
on a per-process basis, simply by touching memory when you allocate
it. Hey presto! You have non-overcommitted VM for your process.
>>> Get used to it, or find another OS...
>>
>> You're such a good Linux advocate...
>
>Hey, this is core stuff that has been in the kernel for a very long time.
>It's not going to change, and it shouldn't be changed.
Agreed.
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