Re: Direct I/O

From: John Naylor <john(dot)naylor(at)enterprisedb(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Direct I/O
Date: 2022-11-10 07:26:20
Message-ID: CAFBsxsFVKzCRYrBMp1DmAN1QFZHnOnGPTKGUVJFHAkFo5kzQ_g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 1, 2022 at 2:37 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)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

In response to

  • Direct I/O at 2022-11-01 07:36:18 from Thomas Munro

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Laurenz Albe 2022-11-10 07:39:29 Re: New docs chapter on Transaction Management and related changes
Previous Message Michael Paquier 2022-11-10 07:01:02 Re: Unit tests for SLRU