Viewing profile — man8alexd

Location: Belgrade, Serbia (UTC+2) Remote: yes (working exclusively remotely for the past 20 years) Willing to relocate: yes Technologies: AWS, Kubernetes, Nomad, Docker, podman, H…

Why do you think it is a better default? What does it solve?

You have a lot of unused anonymous memory that is better swapped out and used as a file cache. Specifically for Linux swap, see https://chrisdown.name/2018/01/02/in-defence-of-swap…

You can't fix the fact that you can't predict the future. The software will always allocate more memory than it needs because it can't predict its future resource usage, so limitin…

About shared memory included in the memory size calculations https://lkml.iu.edu/1902.2/05674.html

The kernel keeps track of active/inactive pages by scanning page tables during the reclaim process. It only scans until it finds enough inactive pages to reclaim. Scanning all page…

You can't know when the OOM killer is awake and hunting. The kernel doesn't know that.

OOM is better. If a program doesn't handle ENOMEM properly, then its state is unpredictable and can lead to data corruption.

Linux MemAvailable from /proc/meminfo is just an estimation calculated as an arbitrary percentage (50%) of free and potentially reclaimable memory. You can't determine how much of …

There is no point in managing memory allocations as they have little relation to actual memory usage. There are also other methods than the OOM killer to handle OOM, like process t…

In this specific case, the correct behaviour would be to drop a part of the buffer pool until the memory pressure is gone. The context-dependent question is how much and how fast t…

Because no one can predict the future, and they don't know how many resources they will need.

Maybe you should skip running a useless child process and just use PSI to monitor memory pressure.

You can always tell the system not to kill your Photoshop (or whatever else) by setting the OOM Score Adjust. This mechanism has existed for almost two decades and systemd has supp…

You will be surprised by how inaccurate memory measurements are.

See this retrocomputing.SE question https://retrocomputing.stackexchange.com/questions/32492/ori...

FreeBSD didn’t have memory overcommit and instead used strict swap reservation - each allocated anonymous memory page was supposed to have a corresponding swap page. This required …

No, it doesn't handle failing allocations gracefully - https://unix.stackexchange.com/questions/797841/firefox-died...

Is Firefox low quality?

People like to reinvent things that they are not aware of. Original BSDs used to use strict swap reservation - every anonymous memory page had to have an associated swap page. You …

MariaDB recently implemented memory PSI monitoring but failed with that in a curious way and disabled it afterwards by default. The failure is that under memory pressure, they flus…

The last paragraph: > On the modern desktop, where programmers don't care about failing malloc(), disabling overcommit is shooting yourself in the foot. As you can observe, the mem…

They do have sidecars like prometheus, node_exporter running alongside Postgres and they include them in their MemoryLimit calculations.

There is some kind of illusion or myth that strict overcommit solves memory management issues.

cgroups have nothing to do with overcommit and memory allocation. They limit actual memory usage for a specific program or group of programs. If this program tries to use more memo…