On 01/09/2014 09:46 PM, Claudio Freire wrote:
> On Thu, Jan 9, 2014 at 2:22 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> It would be nice to have better operating system support for this.
>> For example, IIUC, 64-bit Linux has 128TB of address space available
>> for user processes. When you clone(), it can either share the entire
>> address space (i.e. it's a thread) or none of it (i.e. it's a
>> process). There's no option to, say, share 64TB and not the other
>> 64TB, which would be ideal for us. We could then map dynamic shared
>> memory segments into the shared portion of the address space and do
>> backend-private allocations in the unshared part. Of course, even if
>> we had that, it wouldn't be portable, so who knows how much good it
>> would do. But it would be awfully nice to have the option.
> You can map a segment at fork time, and unmap it after forking. That
> doesn't really use RAM, since it's supposed to be lazily allocated (it
> can be forced to be so, I believe, with PROT_NONE and MAP_NORESERVE,
> but I don't think that's portable).
>
> That guarantees it's free.
>
> Next, you can map shared memory at explicit addresses (linux's mmap
> has support for that, and I seem to recall Windows did too).
>
> All you have to do, is some book-keeping in shared memory (so all
> processes can coordinate new mappings).
As far as I undersand the main advantage of DSM is that segment can be
allocated at any time - not only at fork time.
And it is not because of memory consumption: even without unmap,
allocation of some memory region doesn't cause loose pg physical memory.
And there are usually no problem with exhaustion of virtual space at
64-bit architecture. But using some combination of flags (as
MAP_NORESERVE), it is usually possible to completely eliminate overhead
of reserving some address range in virtual space. But mapping
dynamically created segment (not at fork time) to the same address
really seems to be a big challenge.
