From nobody Sat Jun 20 13:06:27 2026 Received: from out30-101.freemail.mail.aliyun.com (out30-101.freemail.mail.aliyun.com [115.124.30.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 867703CEBBF for ; Wed, 15 Apr 2026 08:23:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.101 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776241394; cv=none; b=PY5pwp7WscOCTA1TefiLR2umcRJKZDN/pYJ9od+kyVroGlt6k0jfaMTIVZURw3R10BbNF+lWREXgB+pDC3Vq5SPGVtJShE36CdyVKKNLqRFacURZfIa+gM79Uabang1p3y73NTIgmZrg37t8tb376sp4Kg5hWx7x5WiNtRJ3i3w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776241394; c=relaxed/simple; bh=M1yyr1apZbgvAtNyfBlB0VWM4j+f3RRrdJG1+8PfMdE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=FicNqOxDGlO9PgZjMAhs7ePLRqUn9RwEbY3Lc+2ID7ejvnE5zLewoRMvXcjt9zC0/1Bc7EvqYdSsOz02nX1NlAaEUSPPWVkgSzDNp72y11sAd1XZXW6GgnPkLQ0oYEkN7rP3HD/S2TxuWyJTUpkB9Qgqv/19dUllkMKKmUOTsu0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=itlSL3vv; arc=none smtp.client-ip=115.124.30.101 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="itlSL3vv" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1776241388; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=A8Fw4KmSyuAbOiS3O+gulAryWNIqUKLF+xq8nrDzkhw=; b=itlSL3vv6rT2TYzHYNjun1V6fFjACIOvUqPsHmxyr+6lAHY79SlGTpTDrr8ZTmxxzqL17KECLivpmhuyFVATwXYarc5YTtGqQbHn1QyWy9oVJvB1aDgmtcwMoHK1gB9MJK1IQplRDqGMfAj83wMfjL+1IbI4Mx5rXSkQB0Zl0q8= X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R111e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033032089153;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=10;SR=0;TI=SMTPD_---0X13xQlN_1776241386; Received: from localhost(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X13xQlN_1776241386 cluster:ay36) by smtp.aliyun-inc.com; Wed, 15 Apr 2026 16:23:07 +0800 From: Baolin Wang To: akpm@linux-foundation.org, hughd@google.com Cc: willy@infradead.org, ziy@nvidia.com, david@kernel.org, ljs@kernel.org, lance.yang@linux.dev, baolin.wang@linux.alibaba.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH v2] mm: shmem: don't set large-order range for internal shmem mount Date: Wed, 15 Apr 2026 16:22:53 +0800 Message-ID: X-Mailer: git-send-email 2.47.3 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Anonymous shmem large order allocations are dynamically controlled via the global THP sysfs knob (/sys/kernel/mm/transparent_hugepage/shmem_enabled) and the per-size mTHP knobs (/sys/kernel/mm/transparent_hugepage/hugepages-= kB/shmem_enabled). Therefore, anonymous shmem uses shmem_allowable_huge_orders() to check which large orders are allowed, rather than relying on mapping_max_folio_or= der(). Moreover, mapping_max_folio_order() is intended to control large order allocations only for tmpfs mounts. Clarify this by not setting a large-order range for internal shmem mount (e.g. anonymous shmem), to avoid confusion, as discussed in the previous thread[1]. [1] https://lore.kernel.org/all/ec927492-4577-4192-8fad-85eb1bb43121@linux.= alibaba.com/ Signed-off-by: Baolin Wang --- Changes from v1: - Update the comments and commit message, per Lance. --- mm/shmem.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/mm/shmem.c b/mm/shmem.c index 4ecefe02881d..568e1baee90d 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -3088,8 +3088,16 @@ static struct inode *__shmem_get_inode(struct mnt_id= map *idmap, if (sbinfo->noswap) mapping_set_unevictable(inode->i_mapping); =20 - /* Don't consider 'deny' for emergencies and 'force' for testing */ - if (sbinfo->huge) + /* + * 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); =20 switch (mode & S_IFMT) { --=20 2.47.3