From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-112.freemail.mail.aliyun.com (out30-112.freemail.mail.aliyun.com [115.124.30.112]) (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 8BB6218AE2 for ; Thu, 16 Apr 2026 02:08:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.112 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776305310; cv=none; b=nx6Wm7mxuhzwOAdvqG2qtF9e+PNsBufAuxcc8wbe7bBlSGTLnrlyQ4fIermt0vDILRO24dXEEHA+yZ+EQ3ZDhyljE2MAFRz+N/jslUiELwqb7y5Qq7c+FZh68U+wEk/B9JQrqrl1RCj5m+KNwOybp2aj5QUENp6u84EsLWTnFhk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776305310; c=relaxed/simple; bh=7pjLZHCshaQqJbrbM2Vc6kQW8mL3n4NDldMYu8ELoTU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=KxVeT76uR7ERQJaCqvJ0WAbpo4HV2S6ZaEag0GFUA6pO1B/EXDrB1veWZY0h5INaOSQl+REzKDchJmrWBqe6zG5Q6P42/Q2XmVTU8+zO/MnWZRsbaeigCPZe6rzfJWwRoP4XVYKU4WzmCmDqRg4vHzukcdMaT5D+HtH4dElvqYw= 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=aQKm9x4s; arc=none smtp.client-ip=115.124.30.112 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="aQKm9x4s" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1776305305; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=13i5phm2ETqjPnWJPbN6WHGGkRFPThnfNwDtCB2m7B8=; b=aQKm9x4snOZg/mth1yFWRqLTY49n4R7cuEa4flff/K7osgvqoPm/wP8/ZdL3DNjl50xqorzk1nwJauMauQ3dDclNtM9tT0gKLSuI38u7nFhIKwqj+diagbbyjKsG6ZRmvdJHYutF0G3FmFphDcJZ+BpQHRrJ98D5LRbG/Og2unc= 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_---0X16ZudU_1776305304; Received: from 30.74.144.131(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X16ZudU_1776305304 cluster:ay36) by smtp.aliyun-inc.com; Thu, 16 Apr 2026 10:08:24 +0800 Message-ID: <50a01c86-fbf1-4f93-9557-6e5cc1dd1dd7@linux.alibaba.com> Date: Thu, 16 Apr 2026 10:08:23 +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 v2] mm: shmem: don't set large-order range for internal shmem mount To: Zi Yan Cc: "David Hildenbrand (Arm)" , willy@infradead.org, akpm@linux-foundation.org, hughd@google.com, ljs@kernel.org, lance.yang@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <2d138a3f-0006-4a01-852a-4570d7ba781d@linux.alibaba.com> <1a3cb6b2-94e0-4268-8cd9-1f9a9deb6c6b@linux.alibaba.com> <875dc63b-0cd2-49e5-8b0d-3fb062789813@kernel.org> <846B17B0-1BAF-4959-8FC2-42744C44B1D6@nvidia.com> <16745f2b-b008-4df1-ac76-f18b4a826dbd@linux.alibaba.com> <4AD72E13-C4AE-4ADA-8AB2-DDB3CEE6A527@nvidia.com> <907b3a20-52b3-4969-8456-bd3a8d2571f2@linux.alibaba.com> From: Baolin Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 4/16/26 9:52 AM, Zi Yan wrote: > On 15 Apr 2026, at 21:45, Baolin Wang wrote: > >> On 4/16/26 9:36 AM, Zi Yan wrote: >>> On 15 Apr 2026, at 21:22, Baolin Wang wrote: >>> >>>> On 4/16/26 9:11 AM, Zi Yan wrote: >>>>> On 15 Apr 2026, at 21:05, Baolin Wang wrote: >>>>> >>>>>> On 4/15/26 10:36 PM, David Hildenbrand (Arm) wrote: >>>>>>> On 4/15/26 12:05, Baolin Wang wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 4/15/26 5:54 PM, David Hildenbrand (Arm) wrote: >>>>>>>>>> >>>>>>>>>> Yes, that makes sense. >>>>>>>>>> >>>>>>>>>> However, it’s also possible that the mapping does not support large >>>>>>>>>> folios, yet anonymous shmem can still allocate large folios via the >>>>>>>>>> sysfs interfaces. That doesn't make sense, right? >>>>>>>>> >>>>>>>>> That's what I am saying: if there could be large folios in there, then >>>>>>>>> let's tell the world. >>>>>>>>> >>>>>>>>> Getting in a scenario where the mapping claims to not support large >>>>>>>>> folios, but then we have large folios in there is inconsistent, not? >>>>>>>>> >>>>>>>>> [...] >>>>>>>>> >>>>>>>>>> >>>>>>>>>> For the current anonymous shmem (tmpfs is already clear, no questions), >>>>>>>>>> I don’t think there will be any "will never have/does never allow" >>>>>>>>>> cases, because it can be changed dynamically via the sysfs interfaces. >>>>>>>>> >>>>>>>>> Right. It's about non-anon shmem with huge=off. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> If we still want that logic, then for anonymous shmem we can treat it as >>>>>>>>>> always "might have large folios". >>>>>>>> >>>>>>>> OK. To resolve the confusion about 1, the logic should be changed as >>>>>>>> follows. Does that make sense to you? >>>>>>>> >>>>>>>> if (sbinfo->huge || (sb->s_flags & SB_KERNMOUNT)) >>>>>>>>     mapping_set_large_folios(inode->i_mapping); >>>>>>> >>>>>>> I think that's better. >>>>>> >>>>>> Thanks for your valuable input. >>>>>> >>>>>> But has Willy says, maybe we can just >>>>>>> unconditionally set it and have it even simpler. >>>>>> >>>>>> However, for tmpfs mounts, we should still respect the 'huge=' mount option. See commit 5a90c155defa ("tmpfs: don't enable large folios if not supported"). >>>>> >>>>> Is it possible to get sbinfo->huge during tmpfs’s folio allocation time, so that >>>>> even if all tmpfs has mapping_set_large_folios() but sbinfo->huge can still >>>>> decide whether huge page will be allocated for a tmpfs? >>>> >>>> Yes, of course. However, the issue isn’t whether tmpfs allows allocating large folios. >>>> >>>> The problem commit 5a90c155defa tries to fix is that when tmpfs is mounted with the 'huge=never' option, we will not allocate large folios for it. Then when writing tmpfs files, generic_perform_write() will call mapping_max_folio_size() to get the chunk size and ends up with an order-9 size for writing tmpfs files. However, this tmpfs file is populated only with small folios, resulting in a performance regression. >>> >>> IIUC, generic_perform_write() needs to use a small chunk if tmpfs denies huge. >>> It seems that Kefeng did that in the first try[1]. But willy suggested >>> the current fix. >>> >>> I wonder if we should revisit Kefeng’s first version. >>> >>> [1] https://lore.kernel.org/all/20240914140613.2334139-1-wangkefeng.wang@huawei.com/ >> >> Personally, I still prefer the current fix (commit 5a90c155defa). We should honor the tmpfs mount option. If it explicitly says no large folios, we shouldn’t call mapping_set_large_folios(). Isn’t that more consistent with its semantics? > > Filesystems wishing to turn on large folios in the pagecache should call > ``mapping_set_large_folios`` when initializing the incore inode. > > You mean tmpfs with huge option set is a FS wishing to turn on large > folios in the pagecache, otherwise it is a FS wishing not to have large folio > in the pagecache. tmpfs with different options is seen as different FSes. What I mean is that tmpfs is somewhat different from other filesystems. We have tried to make tmpfs behave like other FSes, but differences remain. For example, the previous fix to tmpfs’s large folio allocation policy, see commit 69e0a3b49003 ("mm: shmem: fix the strategy for the tmpfs 'huge=' options"). So the tmpfs specific 'huge=' mount option is another way it differs from other filesystems.