Messages in this thread | | | Date | Fri, 17 Mar 2000 09:24:21 +0000 (GMT) | From | James Sutherland <> | Subject | Re: Overcommitable memory?? |
| |
On Fri, 17 Mar 2000, David Whysong wrote: > On Thu, 16 Mar 2000, James Sutherland wrote: > >On Wed, 15 Mar 2000, Paul Jakma wrote: > >> On Mon, 13 Mar 2000, Michael Bacarella wrote: > >> > >> no. Because a good app may have malloc()'ed memory an hour ago, and only > >> now try to write to it. Now the kernel had overcomitted on that > > > >That doesn't happen. malloc() ALLOCATES the memory to the process. It is > >*NOT* overcommitted. It may be backed by swapspace rather than physical > >memory, but that block of memory *IS* available to the process. > > Sorry, you're wrong. No physical memory (RAM or swap) is actually given to > a process until after the program touches the page; malloc() alone is not > sufficient. Proof is below.
Yes, I know. You need to touch the memory before it is really allocated. (snip)
> So malloc() returns success when I ask for an 800 megabyte array on a > machine with only ~640 megabytes of free virtual memory.
It's not supposed to do that, AIUI - malloc() will only succeed if either (a) overcommit_memory is enabled (which disables all sanity checking - you want 2Gb on a 4Mb 386? Here it is...) OR (b) the system stands a *chance* of successfully allocating it (i.e. it has the amount you requested free).
It doesn't ALLOCATE that memory to you immediately - but it is supposed to check that it could do, if needed. (So the source appears to indicate, anyway.)
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/
| |