Re: Linux max on shared buffers?

Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
> So far so good. Now what do you map when? Can you map multiple
> noncontigous 8K blocks out of each file? If so, how do you coordinate
> that all backends in summary use at maximum the number of blocks you
> want PostgreSQL to use (each unique block counts, regardless of how many
> backends have it mmap()'d, right?). And if a backend needs a block and
> the max is reached already, how does it tell the other backends to unmap
> something?

Just to throw some additional wrenches into the gears: some platforms
(eg HPPA) have strong restrictions on where you can mmap stuff.
I quote some interesting material from the HPUX mmap(2) man page below.
Possibly these restrictions could be worked around, but it looks
painful.

Note that platforms where these restrictions don't exist are not
automatically better: that just means that they're willing to swap a
larger number of address translation table entries for each process
dispatch. If we tried to mmap disk file blocks individually, our
process dispatch time would go to hell; but trying to map large ranges
instead (to hold down the number of translation entries) is going to
have a bunch of problems too.

regards, tom lane

If the size of the mapped file changes after the call to mmap(), the
effect of references to portions of the mapped region that correspond
to added or removed portions of the file is unspecified.

[ hence, any extension of a file requires re-mmaping; moreover
it appears that you cannot extend a file *at all* via mmap,
but must do so via write, after which you can re-mmap -- tgl ]

...

Because the PA-RISC memory architecture utilizes a globally shared
virtual address space between processes, and discourages multiple
virtual address translations to the same physical address, all
concurrently existing MAP_SHARED mappings of a file range must share
the same virtual address offsets and hardware translations. PA-RISC-
based HP-UX systems allocate virtual address ranges for shared memory
and shared mapped files in the range 0x80000000 through 0xefffffff.
This address range is used globally for all memory objects shared
between processes.

This implies the following:

o Any single range of a file cannot be mapped multiply into
different virtual address ranges.

o After the initial MAP_SHARED mmap() of a file range, all
subsequent MAP_SHARED calls to mmap() to map the same range
of a file must either specify MAP_VARIABLE in flags and
inherit the virtual address range the system has chosen for
this range, or specify MAP_FIXED with an addr that
corresponds exactly to the address chosen by the system for
the initial mapping. Only after all mappings for a file
range have been destroyed can that range be mapped to a
different virtual address.

o In most cases, two separate calls to mmap() cannot map
overlapping ranges in a file.

[ that statement holds GLOBALLY, not per-process -- tgl ]

The virtual address range
reserved for a file range is determined at the time of the
initial mapping of the file range into a process address
space. The system allocates only the virtual address range
necessary to represent the initial mapping. As long as the
initial mapping exists, subsequent attempts to map a
different file range that includes any portion of the
initial range may fail with an ENOMEM error if an extended
contiguous address range that preserves the mappings of the
initial range cannot be allocated.

o Separate calls to mmap() to map contiguous ranges of a file
do not necessarily return contiguous virtual address ranges.
The system may allocate virtual addresses for each call to
mmap() on a first available basis.