> > Oh, so you're adding/removing physical memory dynamically? > > No. I don't see why you ask this. In my documentation, ulimit sets > a limit for the *current* process, not for the whole system.
I know, but see /etc/initscript. Together with the number of processes (also ulimited), it effectively is a limit for the system. Not the one you like, obviously, but nevertheless a functional one. > > Well, either live with that or add sufficient swap space. > > Wrong remark. Solaris behaves correctly, for instance (i.e. if there > is no memory left, malloc() returns 0, without needing to set limits > on processes). "Correctly"? First, I doubt that Solaris has no overcommitment -- try a test with fork() (it should then fail unless there is enough physical memory left for a second copy of _all_ writeable pages of the current process). Second, I for one would consider the absence of overcommitment as a bad misfeature. Good luck with the kernel bug report. This has been beaten to death many times. For me the alternative is clear: either enjoy the advantages and disadvantages of overcommitment _or_ use "ulimit -v". Regards, Wolfram.
