linux-kernel - Howto prevent kernel from evicting code pages ever? (to avoid disk thrashing when about to run out of RAM)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKYFi-4a=H+vT+vo5s6mpKXAv+0W0pyTj1WtEr6xfjoFVFmtJQ@mail.gmail.com>
Date:   Wed, 22 Aug 2018 11:25:35 +0200
From:   Marcus Linsner <constantoverride@...il.com>
To:     linux-kernel@...r.kernel.org
Subject: Howto prevent kernel from evicting code pages ever? (to avoid disk
 thrashing when about to run out of RAM)

Hi. How to make the kernel keep(lock?) all code pages in RAM so that
kswapd0 won't evict them when the system is under low memory
conditions ?

The purpose of this is to prevent the kernel from causing lots of disk
reads(effectively freezing the whole system) when about to run out of
RAM, even when there is no swap enabled, but well before(in real time
minutes) OOM-killer triggers to kill the offending process (eg. ld)!

I can replicate this consistently with 4G (and 12G) max RAM inside a
Qubes OS R4.0 AppVM running Fedora 28 while trying to compile Firefox.
The disk thrashing (continuous 192+MiB/sec reads) occurs well before
the OOM-killer triggers to kill 'ld' (or 'rustc') process and
everything is frozen for (real time) minutes. I've also encountered
this on bare metal myself, if it matters at all.

I tried to ask this question on SO here:
https://stackoverflow.com/q/51927528/10239615
but maybe I have better luck on this mailing list where the kernel experts are.

Just think of all the frozen systems that you'll be saving(see related
question in the above link, for one), if you figure out the answer to
this, whether be it a kernel patch, or some .config options needing
change, or whatever. Just consider it, whoever you are, reader :)
(probably a kernel god xD 'cause who else would know howto) - I'm
actually selfish, I want this for myself, but I'm more than willing to
share it with all, once I'm aware of it. (this = this howto: let the
OOM-killer kill the offending process asap, without first passing
through disk-thrashing hell freezing the OS ;-) er, I mean Hi, and
how's life? 'll be even better after you've read this, I guarantee it
;-) just believe! synergize)