From: Roman Gushchin <roman.gushchin@linux.dev>
To: Matthew Wilcox <willy@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Regression caused by commit 4687fdbb805a ("mm/filemap: Support VM_HUGEPAGE for file mappings")
Date: Fri, 15 Aug 2025 11:43:25 -0700 [thread overview]
Message-ID: <87plcw8lyq.fsf@linux.dev> (raw)
Hello!
The commit 4687fdbb805a ("mm/filemap: Support VM_HUGEPAGE for file
mappings") causes a regression in our production for containers
which are running short on memory. In some cases they are getting
stuck for hours in a vicious reclaim cycle. Reverting this commit
fixes the problem.
As I understand, the intention of the commit is to allocate large folios
whenever possible, and the idea is to ignore device-specific readahead
settings and the mmap_miss logic to achieve that, which makes total
sense.
However under a heavy memory pressure there must be a mechanism to
revert to order-0 folios, otherwise the memory pressure is inevitable
increased. Maybe mmap_miss heuristics should still be applied? Any other
ideas how to fix it?
Also, a side question: I wonder if it makes sense to allocate 1-2
PMD-sized folios if mapping_large_folio_support() is not there?
Thanks!
next reply other threads:[~2025-08-15 18:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-15 18:43 Roman Gushchin [this message]
2025-08-15 21:01 ` Regression caused by commit 4687fdbb805a ("mm/filemap: Support VM_HUGEPAGE for file mappings") Matthew Wilcox
2025-08-15 22:12 ` Roman Gushchin
2025-08-15 22:21 ` Roman Gushchin
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=87plcw8lyq.fsf@linux.dev \
--to=roman.gushchin@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--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.