Messages in this thread |  | | | Date | Wed, 22 Mar 2000 12:23:23 +0100 (CET) | | From | Marco Colombo <> | | Subject | Re: Overcommittable memory (Was: Some questions about linux kernel.) |
| |
On 21 Mar 2000, Rask Ingemann Lambertsen wrote:
> Den 20-Mar-00 13:12:16 skrev James Sutherland følgende om "Re: Some questions about linux kernel.": > > On Sun, 19 Mar 2000 15:50:07 -0600, you wrote: > > > malloc() just allocates address SPACE. TOUCHING the memory then > > populates that space, which is how I can use malloc() for a nice, > > simple sparse matrix implementation. (On Win32, you have to mess > > around trapping exceptions in userland and allocating the memory > > yourself...) > > Note that malloc() is documented as allocating memory, regardless of > whether you actually touch it or not. Any programmer relies on that.
malloc() is not a system call. It's not a kernel issue. If it does not work as you expect, it's a (documentation) bug.
It uses brk(), which is a system call. bck() is well documented, and does exactly what expected to do. It extends a process address space. No more, no less.
> >>We are talking about the sum of all concurrent requests, and the system > >>aborting when part of the requests already granted turns out to not be > >>granted. > > > No. The malloc() call requested address space, and that succeeded - > > the address space was available. > > > What is NOT available, however, is memory to populate that area fully. > > So what? > > So you have a broken malloc().
"you"? this is not the libc mailing list. And BTW, *my* malloc works exaclty as *I* expect. And it's the standard glibc one.
[...]
.TM. -- ____/ ____/ / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _____/ _____/ _/ Colombo@ESI.it
- 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/
|  |