Re: [PATCH 1/1] Initial mach based shared memory support. - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: [PATCH 1/1] Initial mach based shared memory support.
Date
Msg-id CA+hUKGKao=hLBqn7udCPo721NUSUP8ETLtzG+vWct9KJRETMAQ@mail.gmail.com
Whole thread Raw
In response to [PATCH 1/1] Initial mach based shared memory support.  (James Hilliard <james.hilliard1@gmail.com>)
List pgsql-hackers
On Sun, Nov 22, 2020 at 9:19 PM James Hilliard
<james.hilliard1@gmail.com> wrote:
> In order to avoid hitting these limits we can bypass the wrapper layer
> and just use mach directly.

FWIW I looked into using mach_vm_alllocate() years ago because I
wanted to be able to use its VM_FLAGS_SUPERPAGE_SIZE_2MB flag to
implement PostgreSQL's huge_pages option for the main shared memory
area, but I ran into some difficulty getting such mapping to be
inherited by fork() children.  There may be some way to get past that,
but it seems the current crop of Apple Silicon has only 4KB and 16KB
pages and I don't know if that's interesting enough.  On the other
hand, I just saw a claim that "running an arm64 Debian VM on Apple M1,
using a 16K page size instead of 4K reduces this kernel build time by
*16%*".

[1] https://twitter.com/AtTheHackOfDawn/status/1333895115174187011



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: POC: postgres_fdw insert batching
Next
From: Zhihong Yu
Date:
Subject: Re: Parallel INSERT (INTO ... SELECT ...)