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


____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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