From mboxrd@z Thu Jan 1 00:00:00 1970 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 07FAE3B9DBC for ; Fri, 17 Apr 2026 09:27:55 +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=1776418079; cv=none; b=MEIY9cua/DUZxDPPW83EPM42nvtn9WB8vaDtjBkXXWNrU8Kh/qXyOzJZmD2p2bACpJZaQ9kWdcXYkz825pNqcDafM2aXMVP5YUqXHGZf6WOqs8myJ8d70bbnsR8DwVADtpbWhc5Kq9wg+irn0/JVqit7mN8MPYNqZ5vaCk7E+H8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776418079; c=relaxed/simple; bh=3uINxYpZUnDhqJDundRGZLm89PPBRwUMl8XIi4WCTWo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=E4LjmgZbUHe/816wCFDeNUF6YnVZnf1qgV0ppqJhwddCFWV7T3gzuI2PQGaSfMy+mCr7d1rT6CWBh9Fbb3P56COYxS9cFuFtpdGBj/I46ja9NBCVMzlgNo24swzHdi4qsnXFkrJ34O5NuE43ed2CjKNoy1WiQoxnyAS+QaLWGc0= 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=nIuCsFM/; 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="nIuCsFM/" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1776418066; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=9ban2GK06J3qXdLSyjEj2d7nc7DweKDpF3MVxWR6RWc=; b=nIuCsFM/m0E0iUKUw+m2SPc2HYc9Xy/3LMLj5AdgRUWm/vWQ0wfOQbZdPFGiNm5w8ESHLUIeNK20KjxpWT0MVR/2v8mYn4+3sojbRCy6hvXtcJFS+lr9kWSvE8h9+XMuSK4Ygoy9ByJCnoI3BSEqXG4nJzimceyY7dn6Jk3w5hk= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R281e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033045133197;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---0X1AxuDU_1776418064; Received: from 30.74.144.138(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X1AxuDU_1776418064 cluster:ay36) by smtp.aliyun-inc.com; Fri, 17 Apr 2026 17:27:45 +0800 Message-ID: <015de194-99b9-4f9e-8c89-d35807c6fd08@linux.alibaba.com> Date: Fri, 17 Apr 2026 17:27:44 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] mm: shmem: always support large folios for internal shmem mount To: "David Hildenbrand (Arm)" , akpm@linux-foundation.org, hughd@google.com Cc: willy@infradead.org, ziy@nvidia.com, ljs@kernel.org, lance.yang@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <26f954be62348591e720c4e8b7a9099b74dc1d6d.1776331555.git.baolin.wang@linux.alibaba.com> <1b3c0401-6d10-4a28-97c8-8e3858d8dc3d@kernel.org> From: Baolin Wang In-Reply-To: <1b3c0401-6d10-4a28-97c8-8e3858d8dc3d@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/17/26 5:21 PM, David Hildenbrand (Arm) wrote: > On 4/17/26 05:25, Baolin Wang wrote: >> 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); > > Two questions from a non-fs person about the semantics here: > > a) Can sbinfo->huge be triggered later, for example, through a remount > (staring at shmem_reconfigure()) For tmpfs, yes. > b) Do we cover all cases with the SB_KERNMOUNT where sbinfo->huge cannot > be changed later? For mounts with the SB_KERNMOUNT flag set, which is essentially the internal shmem mount, as we discussed, we don't care about sbinfo->huge. Because for the internal shmem mount, we always consider it as potentially having large folios.