Re: [HACKERS] mmap and MAP_ANON

David Gould wrote:

> - each time a backend wants to use a table it will have to somehow find out
> if it is already mapped, and then either map it (for the first time), or
> attach to an existing mapping created by another backend. This implies
> that the backends need to communicate with all the other backends to let
> them know what mappings they are using.

Why backend has to check if it's already mapped? Let's say that backend
A maps first page from file X using MAP_SHARED, then backend B maps
first page using MAP_SHARED. So, at this moment they are pointing to the
same memory area without any communication. (at least that's the way it
works on Linux, in Linux even MAP_PRIVATE is the same memory region when
you mmap it twice until you write a byte in there - then it's copied).
So, why would we check what other backends map. We use MAP_SHARED to not
have to check it.

> - if two backends are using the same table, and the table is too big to
> map the whole thing, then each backend needs a "window" into the table.
> This becomes difficult if the two backends are using different parts of
> the table (ie, the first page and the last page).

Well I wasn't even thinking on mapping anything more than just one page
that is needed.

> - there is a finite amount of memory available on the system for postgres
> to use. This will have to be split amoung all the open tables used by
> all the backends. If you have 50 backends each using 10 each with 3
> indexes, you now need 2,000 mappings in the system. Assuming that there
> are 2001 pages available for mapping, how do you decide with table gets
> to map 2 pages? How do you get all the backends to agree about this?

IMHO, this is also not that much problem as it looks like. When the
system is running out of virtual memory, the occupied pages are
paged-out. The system does what actually buffer manager does - it writes
down the pages that are dirty, and simply frees memory from those that
are not modified on a last recently used basis. So the only thing that
costs are the memory structures that describe the bindings between disk
blocks and memory. And of course it's sometimes bad to use LRU
algorithm. Sometimes backend knows better which pages are best to
page-out.

I have to admit that this point seems to be potential source of
performance drop-downs and all the backends have to communicate to
prevent it. But I don't think that this communication is huge. Note that
currently all backends use quite large communication channel (256 pages
large by default?) which is hardly used for communication purposes but
rather for storage.

Mike

--
WWW: http://www.lodz.pdi.net/~mimo tel: Int. Acc. Code + 48 42 148340
add: Michal Mosiewicz * Bugaj 66 m.54 * 95-200 Pabianice * POLAND