On Saturday, February 2, 2002, at 01:55 , Scott A Crosby wrote:

> On Sat, 2 Feb 2002, Andreas Raab wrote:
>
>> Daniel,
>>
>>> 	There is no way to guarantee all the memory you
>>> allocate from Malloc is actual ram, and not disk space,
>>> if this is what you are asking....
>>
>> Not quite. The keyword of this discussion is "lazy" not virtual. I 
>> don't
>> exactly care where the memory is (that's exactly what the manager is
>> for). But I _do_ care that if I call malloc() and get a non-null 
>> pointer
>> back then I should in fact be able to use that memory block. According
>
>
> This is called overcommit. Basically, do you overcommit your virtual
> memory resources (memory+swap). If you don't, then trying to start up 
> one
> or two programs that attempt to malloc 512mb, but will only use a 
> fraction
> of it, this will fail.

Mach is intrinsically tied to an overcommit model.  It tends to map 
large chunks of memory as copy-on-write into lots of processes.

> So, you trade flexibility (you only need virtual memory resources to
> sufficidnt for what you're actually going to use) for robustness (The
> systems already promised that it has the memory, which is lying.)

What you need to do is hook up the page-fault handler to the order 
system...more disks for the base-RAID...

> Both views are widely held, sometimes different kernel developers of the
> same kernel. For some kernels, its a runtime option.

Arguing on this list isn't going the change the fact that Mach, and with 
it Darwin/OS-X works like this.

Marcel