linux-kernel - Re: [REGRESSION][BISECTED] Unexpected OOM instead of reclaiming inactive file pages

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-prev] [day] [month] [year] [list]

Message-ID: <15056829.uLZWGnKmhe@natalenko.name>
Date: Mon, 11 Aug 2025 22:42:46 +0200
From: Oleksandr Natalenko <oleksandr@...alenko.name>
To: David Rientjes <rientjes@...gle.com>
Cc: linux-kernel@...r.kernel.org, linux-block@...r.kernel.org,
 Jens Axboe <axboe@...nel.dk>, Damien Le Moal <dlemoal@...nel.org>,
 John Garry <john.g.garry@...cle.com>, Christoph Hellwig <hch@....de>,
 "Martin K. Petersen" <martin.petersen@...cle.com>, linux-mm@...ck.org,
 Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
 Shakeel Butt <shakeel.butt@...ux.dev>, Qi Zheng <zhengqi.arch@...edance.com>,
 Michal Hocko <mhocko@...nel.org>, David Hildenbrand <david@...hat.com>,
 Johannes Weiner <hannes@...xchg.org>,
 Andrew Morton <akpm@...ux-foundation.org>
Subject:
 Re: [REGRESSION][BISECTED] Unexpected OOM instead of reclaiming inactive file
 pages

Hello.

On pondělí 11. srpna 2025 18:06:16, středoevropský letní čas David Rientjes wrote:
> On Mon, 11 Aug 2025, Oleksandr Natalenko wrote:
> 
> > Hello Damien.
> > 
> > I'm fairly confident that the following commit
> > 
> > 459779d04ae8d block: Improve read ahead size for rotational devices
> > 
> > caused a regression in my test bench.
> > 
> > I'm running v6.17-rc1 in a small QEMU VM with virtio-scsi disk. It has got 1 GiB of RAM, so I can saturate it easily causing reclaiming mechanism to kick in.
> > 
> > If MGLRU is enabled:
> > 
> > $ echo 1000 | sudo tee /sys/kernel/mm/lru_gen/min_ttl_ms
> > 
> > then, once page cache builds up, an OOM happens without reclaiming inactive file pages: [1]. Note that inactive_file:506952kB, I'd expect these to be reclaimed instead, like how it happens with v6.16.
> > 
> > If MGLRU is disabled:
> > 
> > $ echo 0 | sudo tee /sys/kernel/mm/lru_gen/min_ttl_ms
> > 
> > then OOM doesn't occur, and things seem to work as usual.
> > 
> > If MGLRU is enabled, and 459779d04ae8d is reverted on top of v6.17-rc1, the OOM doesn't happen either.
> > 
> > Could you please check this?
> > 
> 
> This looks to be an MGLRU policy decision rather than a readahead 
> regression, correct?
> 
> Mem-Info:
> active_anon:388 inactive_anon:5382 isolated_anon:0
>  active_file:9638 inactive_file:126738 isolated_file:0
> 
> Setting min_ttl_ms to 1000 is preserving the working set and triggering 
> the oom kill is the only alternative to free memory in that configuration.  
> The oom kill is being triggered by kswapd for this purpose.
> 
> So additional readahead would certainly increase that working set.  This 
> looks working as intended.

OK, this makes sense indeed, thanks for the explanation. But is inactive_file explosion expected and justified?

Without revert:

$ echo 3 | sudo tee /proc/sys/vm/drop_caches; free -m; sudo journalctl -kb >/dev/null; free -m
3
               total        used        free      shared  buff/cache   available
Mem:             690         179         536           3          57         510
Swap:           1379          12        1367
/* OOM happens here */
               total        used        free      shared  buff/cache   available
Mem:             690         177          52           3         561         513
Swap:           1379          17        1362 

With revert:

$ echo 3 | sudo tee /proc/sys/vm/drop_caches; free -m; sudo journalctl -kb >/dev/null; free -m
3
               total        used        free      shared  buff/cache   available
Mem:             690         214         498           4          64         476
Swap:           1379           0        1379
/* no OOM */
               total        used        free      shared  buff/cache   available
Mem:             690         209         462           4         119         481
Swap:           1379           0        1379

The journal folder size is:

$ sudo du -hs /var/log/journal
575M    /var/log/journal

It looks like this readahead change causes far more data to be read than actually needed?

-- 
Oleksandr Natalenko, MSE
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)