From: Topi Miettinen <toiwoton@gmail.com>
To: Hugh Dickins <hughd@google.com>
Cc: Helge Deller <deller@gmx.de>, Pete Zaitcev <zaitcev@redhat.com>,
linux-mm@kvack.org
Subject: Re: Tmpfs size accounting misses memory allocations
Date: Sun, 3 May 2020 22:58:28 +0300 [thread overview]
Message-ID: <9d509a61-8914-9fc4-b6e8-c157dbb68326@gmail.com> (raw)
In-Reply-To: <alpine.LSU.2.11.2004301902330.2204@eggly.anvils>
I did more testing to find out a more specific test case. It seems that
indeed encrypted swap on LVM logical volume is needed. Swap on
unencrypted LVM volume, encrypted swap on raw partition or no swap at
all is not enough. On those cases, OOM killer starts after both RAM and
swap (if any) has been exhausted and after that it's possible to recover
if essential processes did not get killed. The same happens with either
tmpfs, SysV shm and just malloc().
However, in case swap is on encrypted LVM volume, the system becomes
very unresponsive after RAM (not even swap yet) is filled with either
tmpfs or SysV shm. It's possible to use SysRq and switch VTs (but it
happens slowly). But bash does not respond and the cursor can stop
blinking for a while. OOM killer is not triggered. Manual invocation of
OOM killer with SysRq kills the bad process, but the system never
recovers. Exhausting the RAM+swap with malloc() does not trigger this.
Here's the entry for swap in /etc/crypttab:
cswap /dev/mapper/levy-swap /dev/urandom
cipher=aes-xts-plain64,size=256,hash=sha1,swap
/dev/mapper/levy-swap is a LVM volume on SSD with the same size as RAM
(16GB).
I tested this with Debian kernel 5.6.0-1-amd64.
-Topi
prev parent reply other threads:[~2020-05-03 19:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-25 12:33 Tmpfs size accounting misses memory allocations Topi Miettinen
2020-04-28 1:34 ` Hugh Dickins
2020-04-28 10:51 ` Topi Miettinen
2020-05-01 3:14 ` Hugh Dickins
2020-05-01 7:29 ` Topi Miettinen
2020-05-01 19:05 ` Topi Miettinen
2020-05-03 19:58 ` Topi Miettinen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9d509a61-8914-9fc4-b6e8-c157dbb68326@gmail.com \
--to=toiwoton@gmail.com \
--cc=deller@gmx.de \
--cc=hughd@google.com \
--cc=linux-mm@kvack.org \
--cc=zaitcev@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).