From nobody Tue Jun 16 06:26:30 2026 Received: from out30-124.freemail.mail.aliyun.com (out30-124.freemail.mail.aliyun.com [115.124.30.124]) (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 C33753290C9 for ; Fri, 17 Apr 2026 03:25:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776396362; cv=none; b=Bueyt9ugbdWronMV0xYSf6zpfOcekr9cPEHDBNmIDFnagSdlZ7e0rhx3o7dFZ4qZhjHfbUGfrVLecqJzgxJAW6GnPSViWvUSr0Rx090Kq3OJSI5T0v2Vbgg3X8jUtIcVaMcn3R32Ae1KSzpFXmVPliMP0r51qRPJozduPIp9aNI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776396362; c=relaxed/simple; bh=ybVVlVlEpTir4hMtG9t5/IY4hIj4N56v+Dtbyp3Jh7g=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=to6RBr5fCB1Ia7X2smY4ecICZuNg3QiNaKc60eYZffyilpFgr8zhOBXN170vqaJ6o1ZZNMB42tx99h+EBDV1zE9boUDvUEA/qSovpdcAr3BOf6m4AujX459ZU8/5D4pWw95H+s1xVGpBZOOxSD4RjVEnmr6+lB4t1T+Rs8BdpFg= 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=bVJTtvE2; arc=none smtp.client-ip=115.124.30.124 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="bVJTtvE2" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1776396346; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=jIGmtfqQNV3WWdh9M42ndpoJ6WyORofupaAjImOgxKE=; b=bVJTtvE2lTsUV4O+kHdHyo+GG/wQuoumBkuN5GHuPauRZbKKUsLSOvHA/jNPPAnpRouQ2fxOG/JQwJWBjfuv8qlD7+7MoLfQO1SVSQ9KpeczePn9cOV3Gw0COcW3LrRqxWGEQgARAc+eZUIhUvPRHF27oEChbPTxTx0UE/eJ1qo= X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R151e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033045098064;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=10;SR=0;TI=SMTPD_---0X19y9nz_1776396345; Received: from localhost(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X19y9nz_1776396345 cluster:ay36) by smtp.aliyun-inc.com; Fri, 17 Apr 2026 11:25:46 +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 v3] mm: shmem: always support large folios for internal shmem mount Date: Fri, 17 Apr 2026 11:25:31 +0800 Message-ID: <26f954be62348591e720c4e8b7a9099b74dc1d6d.1776331555.git.baolin.wang@linux.alibaba.com> 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" Currently, when shmem mounts are initialized, they only use 'sbinfo->huge' = to determine whether the shmem mount supports large folios. However, for anony= mous shmem, whether it supports large folios can be dynamically configured via s= ysfs interfaces, so setting or not setting mapping_set_large_folios() during ini= tialization cannot accurately reflect whether anonymous shmem actually supports large f= olios, which has already caused some confusion[1]. As discussed with David[2], for anonymous shmem we can treat it as always p= otentially having large folios. Therefore, always support large folios for the interna= l shmem mount (e.g., anonymous shmem), and which large order allocations are allowe= d can be configured dynamically via the 'shmem_enabled' interfaces. [1] https://lore.kernel.org/all/ec927492-4577-4192-8fad-85eb1bb43121@linux.= alibaba.com/ [2] https://lore.kernel.org/all/875dc63b-0cd2-49e5-8b0d-3fb062789813@kernel= .org/ Signed-off-by: Baolin Wang --- Changes from v2: - Always support large folios for internal shmem mount, per David. Changes from v1: - Update the comments and commit message, per Lance. --- mm/shmem.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/mm/shmem.c b/mm/shmem.c index 4ecefe02881d..769ef37b1ea9 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) + /* + * Always support large folios for the internal shmem mount (e.g., + * anonymous shmem), and which large order allocations are allowed + * can be configured dynamically via the 'shmem_enabled' interfaces. + * + * For tmpfs, honour the 'huge=3D' mount option to determine whether + * large folios are supported. + * + * 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