From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-111.freemail.mail.aliyun.com (out30-111.freemail.mail.aliyun.com [115.124.30.111]) (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 9C36E2DA75A for ; Fri, 17 Apr 2026 12:46:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.111 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776429965; cv=none; b=PLakt5zNibpBSya1ORQ9jgeTYiOlsSlZgxbFJ212t7CUcRhAzrc7z0SZ/3wC6iUwCrfN4u6tYOV1Ebz/OHdtvoDKA0Fv7aohbI5FcZPyvU32y8y3pH7s9i7R3WUeEV1XfwePK00Ou7zEJupL667Fp5aTRuqf63LHnalDyQa+cg0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776429965; c=relaxed/simple; bh=9lI1Jg1Mv8i6ESXhwX4sKnkZRpNeS/W+A1Cw4bzWs7Y=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=KRheKyKV/SLvow1iSV4HzqhYYtyt54urwbBQwwzzw+JI4C1nBXoqrOSThApL300m2mkedfpb11KN3d5ChypG/aGHUZ9o3aLbNRqgeY7b82CNjJLXZDBAfXfRDwdVoBP5e8Pryh/HqLweGqPz5y29/HnWjhyOA8UDB9eXplVa5eU= 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=GayrPppv; arc=none smtp.client-ip=115.124.30.111 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="GayrPppv" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1776429953; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=Ta9DM9SDNRcmSJ5h0e+0G8+56tKcA4LQSKmXx7BeWew=; b=GayrPppvNYlE6+Fg0A/xt/9fXZH27HvqWeyHCJxBCv0umR148hnjPhXyYeWzVifis9tY0GErhcLzU1F7OXAxGPqHWiWUaYMQtlXlHb3kULwF7rAcvEd8e0S56EH5m61RH2xGLoPfVVVAwlWZO/Zx3aQwbz8GSOedWZ23H0g2q9s= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R601e4;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=9;SR=0;TI=SMTPD_---0X1BNHJL_1776429952; Received: from 30.32.70.62(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X1BNHJL_1776429952 cluster:ay36) by smtp.aliyun-inc.com; Fri, 17 Apr 2026 20:45:52 +0800 Message-ID: Date: Fri, 17 Apr 2026 20:45:51 +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> <015de194-99b9-4f9e-8c89-d35807c6fd08@linux.alibaba.com> From: Baolin Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 4/17/26 5:52 PM, David Hildenbrand (Arm) wrote: > On 4/17/26 11:27, Baolin Wang wrote: >> >> >> 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. > > So, we could pass this check here, not setting > mapping_set_large_folios(), but later someone toggles it and we missed > to set mapping_set_large_folios()? Indeed. Good point. > > Or would we always go through another __shmem_get_inode() after a remount? Not really. There could be files created before remount whose mappings don't support large folios (with 'huge=never' option), while files created after remount will have mappings that support large folios (if remounted with 'huge=always' option). It looks like the previous commit 5a90c155defa was also problematic. The huge mount option has introduced a lot of tricky issues:( Now I think Zi's previous suggestion should be able to clean up this mess? That is, calling mapping_set_large_folios() unconditionally for all shmem mounts, and revisiting Kefeng's first version to fix the performance issue. [1] https://lore.kernel.org/all/20240914140613.2334139-1-wangkefeng.wang@huawei.com/