All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gopal Malaviya <gopalmalaviya53@gmail.com>
To: alireza.haddadi@it.uu.se
Cc: jack@suse.cz, willy@infradead.org, akpm@linux-foundation.org,
	vishal.moola@gmail.com, fujunjie1@qq.com,
	roman.gushchin@linux.dev, linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	regressions@lists.linux.dev, tracekotae@gmail.com
Subject: Re: [PATCH] mm/filemap: let sequential faults restart mmap readahead
Date: Wed, 11 Nov 2026 04:23:10 +0000	[thread overview]
Message-ID: <20261111042310.191979-1-gopalmalaviya53@gmail.com> (raw)
In-Reply-To: <20261109-mmap-miss-v1-1-8b44b33f3358@it.uu.se>

Hi Alireza,

I had sent a different fix for the same regression [1], reported by
Trace in [2]. Jan prefers yours, so I have dropped mine. I ran your
patch, also with the v2 change you describe to Jan, through the tests
I had: a KVM guest (x86_64, 2 vCPUs, 3 GiB), mm-hotfixes-unstable as
of 2026-11-08, ext4 and XFS with 16 KiB blocks on virtio-blk,
read_ahead_kb 128 unless noted.

The reproducer from [2] (2000 single-page faults 1 MiB apart, then a
64 MiB sequential read), major faults in the sequential part:

                       base   as posted   with v2 change
  ext4                16384           2                2
  XFS, 16 KiB blocks   4096        4096                2

Touching 1% of the pages of a cold 20 GiB file, larger than memory, in
random runs of 1, 2 or 4 adjacent pages, MiB read from disk with the
v2 change (first of two runs; the second was within 10%):

                       read_ahead_kb 128     read_ahead_kb 8192
                        base   with v2        base   with v2
  random                 259       234        1057      1070
  stride 2053 pages      271       236         992       992
  random 2-page runs     257       373        1135      2538
  random 4-page runs     240      1146        1200     57748

The 4-page runs at read_ahead_kb 8192, which is what this guest's
virtio-blk disk gets by default, read about 48 times more. As far as I
can tell, each run now has two misses and up to two hits on the new
window, so mmap_miss stays around MMAP_LOTSAMISS, and each time it is
back at the limit the next random miss gets the full 8 MiB
read-around. My patch ran into the same and kept mmap_miss at its cap
on that path; something like that may help here, but you and Jan know
this better.

On the Fixes tag: with the commits of the series built one by one,
commit 0b9c0aeba938 ("mm/filemap: count only the faulting address as
a mmap hit") alone does not show the problem (1 major fault with the
reproducer), and commit 9b0fcac3cfe7 ("mm/filemap: do not count
FAULT_FLAG_TRIED retries as mmap hits") does (16384). [2] is the same
regression, in case you want to add Reported-by and Closes tags for
regzbot.

I am happy to run these again on your v2. The tests were set up with
the help of an AI assistant.

[1] https://lore.kernel.org/all/20261109091444.128521-1-gopalmalaviya53@gmail.com/
[2] https://lore.kernel.org/all/20261105192517.228523-1-tracekotae@gmail.com/

Thanks,
Gopal

  parent reply	other threads:[~2026-11-11  4:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-09 14:23 [PATCH] mm/filemap: let sequential faults restart mmap readahead Alireza Haddadi
2026-11-09 14:23 ` Alireza Haddadi via B4 Relay
2026-11-09 17:11 ` Jan Kara
2026-11-09 20:23   ` Alireza Haddadi
2026-11-10 10:37     ` Jan Kara
2026-11-09 18:56 ` sashiko-bot
2026-11-11  4:23 ` Gopal Malaviya [this message]
2026-11-11  7:43   ` Alireza Haddadi
2026-11-13  6:24     ` Gopal Malaviya

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=20261111042310.191979-1-gopalmalaviya53@gmail.com \
    --to=gopalmalaviya53@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=alireza.haddadi@it.uu.se \
    --cc=fujunjie1@qq.com \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=regressions@lists.linux.dev \
    --cc=roman.gushchin@linux.dev \
    --cc=tracekotae@gmail.com \
    --cc=vishal.moola@gmail.com \
    --cc=willy@infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.