On Sun, Jan 11, 2026 at 4:34 PM Zdenek Kabelac <[email protected]> wrote: > You probably do need to configure your systemd-oom killer to prevent getting
[[ I think I know why I get this behaviour, see section "Why dm-integrity behaves so" below. ]] I don't like systemd-oomd. It starts to kill processes long before both memory and swap is full. Let me repeat what I need: I have big RAM and big swap. And I want OOM killer to kill processes only when absolutely necessary, i. e. when both RAM and swap is full. systemd-oomd is opposite of this: it kills processes long before that moment, in misguided attempt to keep the system responsive. But for me my apps are more important than responsiveness. I. e. 4 minutes long freezes I talk about are lesser evil than killing everything. So I explicitly disabled systemd-oomd on my system. > configuration - as OOM is supposed to kill userland RAM hogging task much I will repeat: "free -h" output at that moment showed that my RAM is full, but swap is 23% full (87 Gb out of 378 Gb are used). So, there is a lot of space. > So I think you should also show whole device tree of your system and some more My system is not unusual at all. It is a laptop. With 64 Gb memory and 378 Gb swap. I will repeat: swap is located on dm-integrity. CPU is Intel Core i9. > information - so there is even 'remote' chance trying to reproduce your > scenario. Here are steps to reproduce: - Take some high-specced machine. I. e. this should be machine, which is fast, and which never experiences slowdowns in normal situations - Put swap on dm-integrity in journaled mode - RAM should be 64 Gb and swap should be 378 Gb - Open a lot of Chromium tabs until your RAM is nearly full and your swap is 23% full - Work at your computer for some days (play Youtube videos and perform various other activity) - At some point your whole computer will freeze for some time, say 4 minutes - You will also notice that this happens with journaled dm-integrity mode, but doesn't happen in non-journaled mode - (Kernel version is 6.12.48) I'm nearly sure that everybody will be able to successfully reproduce this. I don't think precise device tree matters. = Why dm-integrity behaves so = I think I know why this happens. - Some process needs memory, but RAM is full - So kernel attempts to send some memory (i. e. some page) to swap - But swap is located on top of dm-integrity - And dm-integrity (in journaled mode) write everything twice: once to journal and then to final place - So dm-integrity layer at first writes that page to journal - But journal is cached. Using so-called dm-bufio cache - And this cache is located in RAM as opposed to disk! - So that page is written to dm-bufio cache, which is located in memory! - Thus this page is not actually removed from memory, it is merely moved from one memory place to another (!!!!!!) - This means that the system is still short of memory (!!!!!) - Thus kernel attempts to flush to swap more memory - But this merely causes whole process to repeat I think that is why I experience freezes. But I'm not sure about this. Also, I will repeat: this is merely an experience report. I'm not really interested in fixing of this bug. I merely sent this report for your information. I personally switched to non-journaled mode, and I'm happy. I'm okay with sharing more info about my setup. But I will not test any patches. -- Askar Safin
