Re: Re: [PATCHES] A patch for xlog.c

> On Sun, Feb 25, 2001 at 11:28:46PM -0500, Tom Lane wrote:
> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > > It allows no backing store on disk.
>
> I.e. it allows you to map memory without an associated inode; the memory
> may still be swapped. Of course, there is no problem with mapping an
> inode too, so that unrelated processes can join in. Solarix has a flag
> to pin the shared pages in RAM so they can't be swapped out.

We don't want to generate i/o to disk just for shared memory
modifications, that is why we can't use a disk file.

>
> > > It is the BSD solution to SysV
> > > share memory. Here are all the BSDi flags:
> >
> > > MAP_ANON Map anonymous memory not associated with any specific
> > > file. The file descriptor used for creating MAP_ANON
> > > must be -1. The offset parameter is ignored.
> >
> > Hmm. Now that I read down to the "nonstandard extensions" part of the
> > HPUX man page for mmap(), I find
> >
> > If MAP_ANONYMOUS is set in flags:
> >
> > o A new memory region is created and initialized to all zeros.
> > This memory region can be shared only with descendants of
> > the current process.
>
> This is supported on Linux and BSD, but not on Solarix 7. It's not
> necessary; you can just map /dev/zero on SysV systems that don't
> have MAP_ANON.

Oh, really. Yes, I have seen people do that.

> > While I've said before that I don't think it's really necessary for
> > processes that aren't children of the postmaster to access the shared
> > memory, I'm not sure that I want to go over to a mechanism that makes it
> > *impossible* for that to be done. Especially not if the only motivation
> > is to avoid having to configure the kernel's shared memory settings.
>
> There are enormous advantages to avoiding the need to configure kernel
> settings. It makes PG a better citizen. PG is much easier to drop in
> and use if you don't need attention from the IT department.

One big advantage is that mmap() removes itself when all processes using
it exit, while SysV stays around and has to be cleaned up manually in
some cases.

> But I don't know of any reason to avoid mapping an actual inode,
> so using mmap doesn't necessarily mean giving up sharing among
> unrelated processes.

See above.

>
> > Besides, what makes you think there's not a limit on the size of shmem
> > allocatable via mmap()?
>
> I've never seen any mmap limit documented. Since mmap() is how
> everybody implements shared libraries, such a limit would be equivalent
> to a limit on how much/many shared libraries are used. mmap() with
> MAP_ANONYMOUS (or its SysV /dev/zero equivalent) is a common, modern
> way to get raw storage for malloc(), so such a limit would be a limit
> on malloc() too.
>
> The mmap architecture comes to us from the Mach microkernel memory
> manager, backported into BSD and then copied widely. Since it was
> the fundamental mechanism for all memory operations in Mach, arbitrary
> limits would make no sense. That it worked so well is the reason it
> was copied everywhere else, so adding arbitrary limits while copying
> it would be silly. I don't think we'll see any systems like that.

This is encouraging.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026