[ cc list trimmed again ]
Ugh, the attributions are getting too deep. James Sutherland and Jesse
Pollard were having this conversation. If I got this wrong, or any
included text was written by someone else, I apologize...
>James Sutherland <jas88@cam.ac.uk>:
>>Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil> wrote:
>>> What do you mean by "overcommit" in this case - the total online user
>>> quota exceeding total VM, or the Linux (memory allocated on demand)
>>> sense?
>>
>>Here overcomit is the total concurrent user quota exceeding total VM. When the
>>users acutally use the memory allocated (memory allocated on demand) the
>>systems can fail/hang/crash/random process abort.
>
>That's a totally different meaning of the word, not the one everyone
>else here is using - and if a simple failed userspace memory
>allocation causes your system to crash, get a refund. It's terminally
>broken.
No. Overcommit means, for example, all user programs have used 1 gigabyte
in total, but your machine only has 256 MB RAM and 512 MB swap. And
malloc() still doesn't fail.
This behavior is *GOOD*.
Lots of that gigabyte of "used" memory may be shared copy-on-write pages
(or malloc()'ed pages, etc.) that will never be written to, and therefore
never page-faulted. So these pages will always be absent, because even
though technically they are "used", nothing will ever actually use them.
>>> You still don't appear to understand what overcommit means in this
>>> context.
>>
>>"overcommit": The sum of all concurrent process virtual memory ranges (in
>> pages) exceeds the number of pages in main memory plus swap
>> memory.
>>
>>virtual memory range: That addressable memory requested by a process and
>> allocated to the process by the kernel via sbrk, fork, exec,
>> and stack. (mmap should be included too, but I don't know
>> for sure yet.)
>
>The issue being referred to as "overcommit" in Linux is the fact Linux
>does not include unused malloc() address space in this, since there is
>nothing in that space yet. If your system is forced to be
>overcommitted by your definition, you DO have problems.
I don't quite understand what you mean, but I'm pretty sure it's wrong
anyway. :-)
>>There is still some memory not accounted for here - memory buffers for
>>I/O, kernel addressing requirements, TCP, driver pools, etc.
>>
>>The primary usage of memory is covered.
>
>This is not the usage in this thread.
Uh, it has been for me...
Dave
David Whysong dwhysong@physics.ucsb.edu
Astrophysics graduate student University of California, Santa Barbara
My public PGP keys are on my web page - http://www.physics.ucsb.edu/~dwhysong
DSS PGP Key 0x903F5BD6 : FE78 91FE 4508 106F 7C88 1706 B792 6995 903F 5BD6
D-H PGP key 0x5DAB0F91 : BC33 0F36 FCCD E72C 441F 663A 72ED 7FB7 5DAB 0F91
-
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:14 EST