On Fri, 17 Mar 2000, Andreas Bombe wrote:
> On Thu, Mar 16, 2000 at 11:22:17AM +0000, 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?
> >
> > (i always thought malloc()'s were noted by the kernel ie in the page
> > table for the process, but that the kernel didn't actually allocate a
> > real page until the process tried to access that page - ie malloc() is
> > overcommited)
>
> Looking at the sources of do_brk(), it faults in the pages (thereby
> assuring they will exist for the process) only if the process' VM is
> locked (mlockall()). Also, it returns with ENOMEM only[1] if
> vm_enough_memory() says there isn't enough mem, but this function only
> examines a snapshot of mem usage at the time of the call (and is
> always successful if overcommit is set to on).
Yes - a bit optimistic, that... IMO, there should be a "tell the truth"
option, to allocate memory when asked to allocate memory.
> Unless I misunderstand the sources (I'm not a Linux VM expert), malloc
> will overcommit.
Yes, unless you jump through a few hoops to disable it...
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:19 EST