Messages in this thread | | | Date | Thu, 16 Mar 2000 23:59:02 +0000 (GMT) | From | James Sutherland <> | Subject | Re: Overcommitable memory?? |
| |
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/
| |