From nobody Mon Jun 15 00:09:41 2026 Received: from out30-100.freemail.mail.aliyun.com (out30-100.freemail.mail.aliyun.com [115.124.30.100]) (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 3011E21257F for ; Tue, 7 Apr 2026 06:07:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.100 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775542065; cv=none; b=b7EF9kr3Wr9fsL/ZwbmvVTjL1g+7wMcvqhRhK47/Cb5slDWJS3/HdtT2LhXLBdONGTWqFk8psGkGNItGpwFNWjJrVJNpILN4drbiUfYCbuwM3TJJMfJkC6owF2Rn9oMsc4rK5SMm26b9z/JaGp/0twKwrhDaYLSWrkYs4cKkr3E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775542065; c=relaxed/simple; bh=Vl3ohNM5PP+zO3uUTq8cJBeLotCF0scfK+8dNPAZr20=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=Zdy+8jIGnFRR0tFy5ZgyAihoC8iSpXTSuVGVIGtJAOC5NHbAWwB95qR3zQ+WMgDyQpSftMROaVkutn8uXYZEZ+lqGO556wqG+ahatjVhXlfMim+xOSXKMbHWCCX0J0jYWZmvHYdHrUNw7TbG44xM0SBEaJfFFV35G2ZalCuYmW0= 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=fhF+zVsD; arc=none smtp.client-ip=115.124.30.100 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="fhF+zVsD" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1775542060; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=dr/WlAAYQOkNiis0A0/5gkZYDAwsfw4TSX3WTt3umOI=; b=fhF+zVsDcqQ7nUXn5YePiYGVcgE/fjFCBQUAG+nya4wfhT8plF6rIfV8955FvuVlKHVHSsoGnFfrx+SQOKxUWb6qo5Ym0i5qE42fYn5xbmxzo1oOrAHrmB/zWJibGDauKP0FcWIcwembgj72gYnHPSMBRgJWwAyKy3melbmHbVM= X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R471e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037009110;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=10;SR=0;TI=SMTPD_---0X0apgMa_1775542059; Received: from localhost(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X0apgMa_1775542059 cluster:ay36) by smtp.aliyun-inc.com; Tue, 07 Apr 2026 14:07:40 +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] mm: shmem: don't set large-order range for internal anonymous shmem mapping Date: Tue, 7 Apr 2026 14:07:27 +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 anonymous shmem mappings, to avoid confusion, as discuss= ed in the previous thread[1]. [1] https://lore.kernel.org/all/ec927492-4577-4192-8fad-85eb1bb43121@linux.= alibaba.com/ Signed-off-by: Baolin Wang --- mm/shmem.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/mm/shmem.c b/mm/shmem.c index 4ecefe02881d..a60fe067969c 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -3088,8 +3088,17 @@ 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 anonymous shmem mount is configured + * dynamically via the 'shmem_enabled' interfaces, so there is no + * need to set a large order range for the internal anonymous shmem + * 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