From: Matthew Wilcox <willy@infradead.org>
To: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: akpm@linux-foundation.org, hughd@google.com, ziy@nvidia.com,
david@kernel.org, ljs@kernel.org, lance.yang@linux.dev,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mm: shmem: don't set large-order range for internal shmem mount
Date: Wed, 15 Apr 2026 14:45:07 +0100 [thread overview]
Message-ID: <ad-WY2B_9OxyWlzX@casper.infradead.org> (raw)
In-Reply-To: <ef418d0f8c17a949952f1f023bef658041956ecd.1776241278.git.baolin.wang@linux.alibaba.com>
On Wed, Apr 15, 2026 at 04:22:53PM +0800, Baolin Wang wrote:
> + /*
> + * Only set the large order range for tmpfs mounts. The large order
> + * selection for the internal shmem mount is configured dynamically
> + * via the 'shmem_enabled' interfaces, so there is no need to set a
> + * large order range for the internal shmem mount's mapping.
> + *
> + * Note: Don't consider 'deny' for emergencies and 'force' for
> + * testing.
> + */
> + if (sbinfo->huge && !(sb->s_flags & SB_KERNMOUNT))
> mapping_set_large_folios(inode->i_mapping);
This isn't how mapping_set_large_folios() is supposed to be used.
It's supposed to indicate "does the filesystem support large folios".
shmem should be setting it unconditionally and if there needs to be some
other way to prevent large folios from being created, we should do that
instead.
The current code is wrong too.
prev parent reply other threads:[~2026-04-15 13:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-15 8:22 Baolin Wang
2026-04-15 8:47 ` David Hildenbrand (Arm)
2026-04-15 9:04 ` Baolin Wang
2026-04-15 9:19 ` David Hildenbrand (Arm)
2026-04-15 9:41 ` Baolin Wang
2026-04-15 9:54 ` David Hildenbrand (Arm)
2026-04-15 10:05 ` Baolin Wang
2026-04-15 14:36 ` David Hildenbrand (Arm)
2026-04-15 13:45 ` Matthew Wilcox [this message]
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=ad-WY2B_9OxyWlzX@casper.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=david@kernel.org \
--cc=hughd@google.com \
--cc=lance.yang@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=ziy@nvidia.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox