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
chunkof 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
away to tell the kernel (or glibc) to simply reserve a chunk of virtual address space for further user. Not sure if
there'sa 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.