linux-kernel - vfs-keep-inodes-with-page-cache-off-the-inode-shrinker-lru.patch

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]

Date:   Mon, 8 Nov 2021 10:57:23 -0500
From:   Johannes Weiner <hannes@...xchg.org>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        kernel-team@...com
Subject: vfs-keep-inodes-with-page-cache-off-the-inode-shrinker-lru.patch

Hi Andrew,

I promised to give this patch some more testing exposure while it sits
in -mm. We've been steadily rolling this version of the change to our
fleet over the last months and it's currently on 20% of FB servers. We
have not noticed crashes or performance regressions because of it.
(The other 80% is running a previous version of the patch.)

The comment in 'series' says "extra cycle" but that was 5.15 :-) Do
you think we can get it merged into 5.16?

Just to reiterate, without the patch, there is very broad production
breakage for FB beyond reduced cache effectiveness. Yes, we lose cache
pages prematurely. But a bigger problem is that we lose nonresident
info we store in the inodes. This defeats thrash detection, which in
turn defeats psi and central reclaim deciscion making. The downstream
effects of this are quite severe and widespread:

- memory prioity inversion between containers
- failure to offload cold memory to swap with proactive reclaim
- breakdown of container health monitoring and userspace OOM killing

I'm not exaggerating when I say we can't reliably operate our fleet
without this patch. We've had to carry variants of it for two years
now. It'd be great to get this fixed upstream.

Thanks,
Johannes