Re: Hard system lock-ups when using encrypted swap and RAM is exhausted

[Askar Safin <safinaskar@gmail.com>]

On Sun, Jan 11, 2026 at 4:34 PM Zdenek Kabelac <zkabelac@redhat.com> 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