linux-kernel - Re: [PATCH] mm: consider disabling readahead if there are signs of thrashing

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

Message-Id: <20250710135713.916a4898fb02f595206ac861@linux-foundation.org>
Date: Thu, 10 Jul 2025 13:57:13 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Roman Gushchin <roman.gushchin@...ux.dev>
Cc: Jan Kara <jack@...e.cz>, Matthew Wilcox <willy@...radead.org>,
 linux-mm@...ck.org, linux-kernel@...r.kernel.org, Liu Shixin
 <liushixin2@...wei.com>
Subject: Re: [PATCH] mm: consider disabling readahead if there are signs of
 thrashing

On Thu, 10 Jul 2025 12:52:32 -0700 Roman Gushchin <roman.gushchin@...ux.dev> wrote:

> We've noticed in production that under a very heavy memory pressure
> the readahead behavior becomes unstable causing spikes in memory
> pressure and CPU contention on zone locks.
> 
> The current mmap_miss heuristics considers minor pagefaults as a
> good reason to decrease mmap_miss and conditionally start async
> readahead. This creates a vicious cycle: asynchronous readahead
> loads more pages, which in turn causes more minor pagefaults.
> This problem is especially pronounced when multiple threads of
> an application fault on consecutive pages of an evicted executable,
> aggressively lowering the mmap_miss counter and preventing readahead
> from being disabled.
> 
> To improve the logic let's check for !uptodate and workingset
> folios in do_async_mmap_readahead(). The presence of such pages
> is a strong indicator of thrashing, which is also used by the
> delay accounting code, e.g. in folio_wait_bit_common(). So instead
> of decreasing mmap_miss and lower chances to disable readahead,
> let's do the opposite and bump it by MMAP_LOTSAMISS / 2.

Are there any testing results to share?

What sort of workloads might be harmed by this change?

We do seem to be thrashing around (heh) with these readahead
heuristics.  Lots of potential for playing whack-a-mole.  

Should we make the readahead code more observable?  We don't seem to
have much in the way of statistics, counters, etc.  And no tracepoints,
which is surprising.