On Fri, 24 Mar 2000, Sandy Harris wrote:
> Alan Cox wrote:
> >
> > > The explanation is not the issue. The issue is having programs that
> > > act correctly (check malloc() returns, don't follow null pointers,
> > > etc.) fail in ways that are quite difficult for their programmers
> > > to prevent.
> >
> > Indeed. And its completely valid to kill them off. Right now nobody
> > has a serious commercial requirement for non-overcommit on Linux.
>
> I'm seriously confused by this thread.
>
> If I understand correctly, programs can malloc() memory, get back a
> valid pointer, then segfault later when they try to use the memory.
> This strikes me as quite obviously Wrong.
It's not. "memory" is the confusing word here. malloc() allocates
memory. But "memory" here is just a concept. fwrite() writes to a
"file", which is again just a concept. Nothing is said about the actual
implementation.
for(;;); is a valid piece of C. According to the Standard it will
run Forever. On any real implementation, this is not obviosly true.
A (UNIX) process may request "memory" to the kernel. Again, memory
is not a real object. It's an abstraction. The kernel has to allocate
resources (RAM, disk, whatever) to implement that abstraction.
The OS may kill a signal to a process for many reasons. Even if
the source is not C. The language a program is written with is not
an OS matter. So what the malloc() manual has to say, has little meaning.
The kernel interface is brk() (or mmap()). Brk() manual is clear.
It's a matter of address space. It allows you to "name" more objects,
but no one is giving you real objects (or room to store them).
> I can see no question about whether this is a problem. To me, it clearly
> is, and a ghastly one at that. This breaks the basic behaviour of
> important system calls, making memory allocation unreliable.
>
> It is not clear to me why anyone would implement overcommit in the
> first place or, once the obvious problem is pointed out, why there
> should be discussion of anything other than how to fix the blunder.
>
> On the other hand, I see several people, some of whom I know are
> competent, defending the existing behaviour.
It increases system throughput.
[...]
.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/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:17 EST