Linux 7.0 Broke PostgreSQL: The Preemption Regression Explained • Hacker News Board

Re: Linux 7.0 Broke PostgreSQL: The Preemption Regression Explained

#71

Post by rcxdude » Thu, Apr 30, 2026, 11:49 AM UTC

AlienRobot wrote: post #54

rcxdude wrote: post #41

Earlier quoted context omitted.

This issue is much worse if you don't have swap. What happens, I think, is that as memory allocated by processes grows to fill the available RAM, it starts to push out memory that doesn't technically need to be in RAM, like cached file pages. Which accounts for some of the slowdown, until it reaches the code itself, which is 'just' a memory mapped file. So eventually most of the code that is actively trying to run is…

Yes, but the problem, I feel, is the priority of what gets pushed out to RAM on Linux. You could split the processes into 2 categories: 1: applications that are doing tasks the user wants. 2: OS processes that the user needs to interact with in order to terminate applications. There is an argument for applications taking priority: the user wants to do a task, if you move application out of RAM, the task is going to t…

The issue is, if you don't have swap, then it's not matter of prioritisation: there are some things in RAM that can't be pushed out, regardless of how unimportant they are (so the only recourse is to terminate some processes, usually the ones using the most RAM. Linux the kernel by default tries really had not to do this, which is why there are userspace applications like earlyoom to do it, which is probably the better location for such logic).

And yeah, you can adjust the priorities and the latency/throughput tradeoff (even per-application to some extent), but it's a difficult thing to get right in general (what works for one use-case might make another a lot worse). I don't know of any DE that really tries to adjust this, though (not because the kernel can't, but probably because no-one on the DE side has really prioritised it or they have tried and it hasn't made a noticable difference).

Re: Linux 7.0 Broke PostgreSQL: The Preemption Regression Explained

#72

Post by singron » Thu, Apr 30, 2026, 2:44 PM UTC

AlienRobot wrote: post #54

rcxdude wrote: post #41

Earlier quoted context omitted.

This issue is much worse if you don't have swap. What happens, I think, is that as memory allocated by processes grows to fill the available RAM, it starts to push out memory that doesn't technically need to be in RAM, like cached file pages. Which accounts for some of the slowdown, until it reaches the code itself, which is 'just' a memory mapped file. So eventually most of the code that is actively trying to run is…

Yes, but the problem, I feel, is the priority of what gets pushed out to RAM on Linux. You could split the processes into 2 categories: 1: applications that are doing tasks the user wants. 2: OS processes that the user needs to interact with in order to terminate applications. There is an argument for applications taking priority: the user wants to do a task, if you move application out of RAM, the task is going to t…

A specific process can use mlockall to keep all its mapped memory resident and prevent swapping or page cache eviction. That's what earlyoom does so that it can stay responsive when memory gets low. It's unfortunately underutilized in other infrastructure. It's also all-or-nothing: everything stays resident until it's munlocked regardless of how frequently it's used.

I had hoped that something like Linux Pressure Stall Information (PSI) would become more useful for low-memory scenarios. E.g. you could put critical processes in a cgroup that could rate-limit swap-outs/evictions so that it was always responsive. There are some cgroup knobs that affect reclamation, but you need a really good guess about how much memory something needs, which makes it hard to use.

https://docs.kernel.org/accounting/psi.html

Re: Linux 7.0 Broke PostgreSQL: The Preemption Regression Explained

#73

Post by fc417fc802 » Thu, Apr 30, 2026, 10:57 PM UTC

nijave wrote: post #15

dist-epoch wrote: post #12

Earlier quoted context omitted.

Many people have desktops with 128 GB RAM. Should they enable hugepages? I've never heard this recommendation for a desktop.

Huge pages is good when a single process is reserving a giant block of memory which I think isnt that common. You might have transparent huge pages on by default depending on the distro

No idea about hugepages but mmaping giant blocks of memory is extremely common. IIRC Chrome maps something like 1 TB on startup.

I think (?) you don't actually see benefit from hugepages unless you actually write to a large amount of memory though.