lkml.org 
[lkml]   [2000]   [Mar]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.237 / U:0.632 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site