lkml.org 
[lkml]   [2000]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Overcommitable memory??
James Sutherland wrote:
> On Thu, 16 Mar 2000, Paul Jakma wrote:
> > On Thu, 16 Mar 2000, James Sutherland wrote:
> > > On Wed, 15 Mar 2000, Paul Jakma wrote:
> > > 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.
> >
> > so malloc() isn't overcommited? malloc()'ed memory is guaranteed to be
> > available - ie the memory is reserved and accounted for at malloc()
> > time?
>
> malloc() CAN be overcommitted. If you set a VM flag via /proc, then
> malloc() will *ALWAYS* succeed, even if there isn't any memory available
> at all. With the flag clear, malloc() does some sanity checking before
> granting the memory.
>
> You CAN obtain an overcommit free malloc() by clearing the VM flag (it is
> clear by default), then touching every page you allocate when you allocate
> it.

No, this will just result in your process SIGBUS'ing. The current
do_mmap (in mmap_fixup) will call make_pages_present(). There's no error
return. It'll just die if one of the pages could not be faulted.

--
John Ripley, empeg Ltd.
http://www.empeg.com

-
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.744 / U:1.420 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site