Waiting for Postgres 18: Accelerating Disk Reads with Asynchronous I/O

Re:Waiting for Postgres 18: Accelerating Disk Reads with Asy... by anarazel on Wednesday May 07, 2025 @02:25PM (#43919053)

From what I've seen a surprisingly large part of the overhead is due to SMAP when doing larger reads from the page cache - i.e. if I boot with clearcpuid=smap (not for prod use!), larger reads go significantly faster. On both Intel and AMD CPUs interestingly.

On Intel it's also not hard to simply reach the per-core memory bandwidth with modern storage HW. This matters most prominently for writes by the checkpointing process, which needs to compute data checksums given the current postgres implementation (if enabled). But even for reads it can be a bottleneck, e.g. when prewarming the buffer pool after a restart.

[ Parent | on HN ]

Re:Waiting for Postgres 18: Accelerating Disk Reads with Asy... by amluto on Wednesday May 07, 2025 @08:29PM (#43921846)

SMAP overhead should be roughly constant, and I’d be quite surprised if it’s noticeable for large reads. Small reads are a different story.

[ Parent | on HN ]

Re:Waiting for Postgres 18: Accelerating Disk Reads with Asy... by anarazel on Wednesday May 07, 2025 @08:34PM (#43921876)

It turns out to be the other way round, curiously. The bigger the reads (i.e. how much to read in one syscall) and the bigger the target area of the reads (how long before a target memory location is reused), the bigger the overhead of SMAP gets.

If interesting I can dig up the reproducer I had at some point.

[ Parent | on HN ]

Re:Waiting for Postgres 18: Accelerating Disk Reads with Asy... by amluto on Thursday May 08, 2025 @05:56AM (#43924688)

That is definitely interesting.

[ Parent | on HN ]

Re:Waiting for Postgres 18: Accelerating Disk Reads with Asy... by derefr on Wednesday May 07, 2025 @08:29PM (#43921847)

> if I boot with clearcpuid=smap (not for prod use!), larger reads go significantly faster. On both Intel and AMD CPUs interestingly.

Is there a page anywhere that collects these sorts of "turn the whole hardware security layer off" switches that can be flipped to get better throughput out of modern x86 CPUs, when your system has no real attack surface to speak of (e.g. air-gapped single-tenant HPC)?

[ Parent | on HN ]

Re:Waiting for Postgres 18: Accelerating Disk Reads with Asy... by the8472 on Thursday May 08, 2025 @05:24AM (#43924509)

On the kernel side there's a boot parameter for all of them: mitigations=off Software that was compiled with additional fences may have to be recompiled to remove them.

https://www.kernel.org/doc/html/latest/admin-guide/kernel-pa...

[ Parent | on HN ]

Re:Waiting for Postgres 18: Accelerating Disk Reads with Asy... by starspangled on Thursday May 08, 2025 @10:02AM (#43926182)

mitigations=off disables workarounds for bugs or "mis-features" in the CPU that could be exploited to bypass OS security measures.

smap is an OS security measure, and so does not get disabled by mitigations=off. smap can be pretty draining for certain IO performance though. IMO it should be more well-known or covered by a more obvious option.

Linux kernel developers are really bad at defining and naming options like this.

[ Parent | on HN ]