On Wed, Jan 29, 2020 at 2:49 PM Kohei KaiGai <kaigai@heterodb.com> wrote:
> 2020年1月29日(水) 4:27 Thomas Munro <thomas.munro@gmail.com>:
> > On Tue, Jan 28, 2020 at 2:55 PM Kohei KaiGai <kaigai@heterodb.com> wrote:
> > FWIW the code in https://commitfest.postgresql.org/26/2325/ ran into
> > exactly the same problem while making nearly exactly the same kind of
> > thing (namely, a MemoryContext backed by space in the main shm area,
> > in this case reusing the dsa.c allocator).
> >
> Thanks, I had looked at "Shared Memory Context" title on pgsql-hackers a few
> months ago, however, missed the thread right now.
>
> The main point of the differences from this approach is portability of pointers
> to shared memory chunks. (If I understand correctly)
> PG-Strom preserves logical address space, but no physical pages, on startup
> time, then maps shared memory segment on the fixed address on demand.
> So, pointers are portable to all the backend processes, thus, suitable to build
> tree structure on shared memory also.
Very interesting. PostgreSQL's DSM segments could potentially have
been implemented that way (whereas today they are not mapped with
MAP_FIXED), but I suppose people were worried about portability
problems and ASLR. The Windows port struggles with that stuff.
Actually the WIP code in that patch reserves a chunk of space up front
in the postmaster, and then puts a DSA allocator inside it. Normally,
DSA allocators create/destroy new DSM segments on demand and deal with
the address portability stuff through a lot of extra work (this
probably makes Parallel Hash Join slightly slower than it should be),
but as a special case a DSA allocator can be created in preexisting
memory and then not allowed to grow. In exchange for accepting a
fixed space, you get normal shareable pointers. This means that you
can use the resulting weird MemoryContext for stuff like building
query plans that can be used by other processes, but when you run out
of memory, allocations begin to fail. That WIP code is experimenting
with caches that can tolerate running out of memory (or at least that
is the intention), so a fixed sized space is OK for that.
> This article below introduces how our "shared memory context" works.
> It is originally written in Japanese, and Google translate may
> generate unnatural
> English. However, its figures probably explain how it works.
>
https://translate.google.co.jp/translate?hl=ja&sl=auto&tl=en&u=http%3A%2F%2Fkaigai.hatenablog.com%2Fentry%2F2016%2F06%2F19%2F095127
Thanks!
