From mboxrd@z Thu Jan 1 00:00:00 1970 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: 8bit Currently, when shmem mounts are initialized, they only use 'sbinfo->huge' to determine whether the shmem mount supports large folios. However, for anonymous shmem, whether it supports large folios can be dynamically configured via sysfs interfaces, so setting or not setting mapping_set_large_folios() during initialization cannot accurately reflect whether anonymous shmem actually supports large folios, which has already caused some confusion[1]. As discussed with David[2], for anonymous shmem we can treat it as always potentially having large folios. Therefore, 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. [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_idmap *idmap, if (sbinfo->noswap) mapping_set_unevictable(inode->i_mapping); - /* 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=' 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); switch (mode & S_IFMT) { -- 2.47.3