I don't see the relevance to linux-raid either, but the 2.2.x kernel does
have /proc/sys/vm/overcommit_memory which will enable the below behaviour.
It's off by default though...
---
tani hosokawa
river styx internet
On Tue, 27 Apr 1999, Gianni Mariani wrote:
> Benno Senoner wrote:
> ...
>
> >
> > 1)
> > my frist BIG QUESTION is if there is a design flaw in malloc() or not:
>
> No, malloc() should return nil if the memory requested cannot be backed
> by real storage. However, some unicies are configured to perform just as
> you discovered
> because much of the memory "allocated" is not actually touched. I'm not
> sure what the Linux levers are but I'd expect there is a way to switch on
> available memory accounting. The other trick on IRIX was the ability to
> add an amount of swap memory that was actually not backed. The size of
> this kind of swap was tuned by the user to get the best behaviour.
> Pedantic users didn't allow this kind over over-booking of backing store.
>
> If you are allocating such big chunks and you have a multi-user system,
> it may actually be preferable to allocate your data from a mmap()ed file
> so you can guarentee the availability of backing store. I have yet to
> see a version of "amalloc()" for Linux, but that would be helpful if you
> want to malloc out of a mapped file. It could also be used as a fast IPC
> mechanism but your malloc() would need to use relative adresses
> to be really safe.
>
> I'm curious why you would send this question through linux-raid ?
>
>
>
>
