On Mon, Jun 20, 2011 at 04:16:58PM +0200, Florian Pflug wrote: > On Jun20, 2011, at 15:27 , Radosław Smogura wrote: > > 1. mmap some large amount of anonymous virtual memory (this will be maximum > > size of shared memory). > > ... > > Point 1. will no eat memory, as memory allocation is delayed and in 64bit > > platforms you may reserve quite huge chunk of this, and in future it may be > > possible using mmap / munmap to concat chunks / defrag it etc. > > I think this breaks with strict overcommit settings (i.e. > vm.overcommit_memory = 2 on linux). To fix that, you'd need a way to tell the > kernel (or glibc) to simply reserve a chunk of virtual address space for > further user. Not sure if there's a API for that...
I run discless swapless cluster systems with zero overcommit (i.e. it's entirely disabled), which means that all operations are strict success/fail due to allocation being immediate. mmap of a large amount of anonymous memory would almost certainly fail on such a setup--you definitely can't assume that a large anonymous mmap will always succeed, since there is no delayed allocation. [we do in reality have a small overcommit allowance to permit efficient fork(2), but it's tiny and (in this context) irrelevant] Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
signature.asc
Description: Digital signature
