Re: Direct I/O - Mailing list pgsql-hackers

From John Naylor
Subject Re: Direct I/O
Date
Msg-id CAFBsxsFVKzCRYrBMp1DmAN1QFZHnOnGPTKGUVJFHAkFo5kzQ_g@mail.gmail.com
Whole thread Raw
In response to Direct I/O  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Direct I/O
List pgsql-hackers

On Tue, Nov 1, 2022 at 2:37 PM Thomas Munro <thomas.munro@gmail.com> wrote:

> Memory alignment patches:
>
> Direct I/O generally needs to be done to/from VM page-aligned
> addresses, but only "standard" 4KB pages, even when larger VM pages
> are in use (if there is an exotic system where that isn't true, it
> won't work).  We need to deal with buffers on the stack, the heap and
> in shmem.  For the stack, see patch 0001.  For the heap and shared
> memory, see patch 0002, but David Rowley is going to propose that part
> separately, as MemoryContext API adjustments are a specialised enough
> topic to deserve another thread; here I include a copy as a
> dependency.  The main direct I/O patch is 0003.

One thing to note: Currently, a request to aset above 8kB must go into a dedicated block. Not sure if it's a coincidence that that matches the default PG page size, but if allocating pages on the heap is hot enough, maybe we should consider raising that limit. Although then, aligned-to-4kB requests would result in 16kB chunks requested unless a different allocator was used.

--
John Naylor
EDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Unit tests for SLRU
Next
From: Laurenz Albe
Date:
Subject: Re: New docs chapter on Transaction Management and related changes