From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-118.freemail.mail.aliyun.com (out30-118.freemail.mail.aliyun.com [115.124.30.118]) (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 9F4E6328B77 for ; Wed, 15 Apr 2026 10:05:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.118 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776247531; cv=none; b=GzYpLSiJsHJ6PgDIzZZ13kQOrx1Nn/8HPsNJDNHC96oVfUDFPg9p3cDj+NlA8VGSuddP/RR9nhU+KfzpoeY+QyeOggM/mu2Xa1NKa9XXFpxUSC84ua0UK/CBUnpAExt2CdfcAFTH0TP0pzcBakAbJex99lzb/RDtRTCfVCIgXoI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776247531; c=relaxed/simple; bh=ct70g40/Bkdi6jt4lZAQdYhV+Hh152g6CuQ0NhoCTlQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=SH301YhdnY+GO626EM2EruBTPlpWlbg3Q05H1kGjw8tR96f+vhcgC0PBce7iaDJlnQeudvj/FogsWUp3aXUNTrU0HE/umxv1on3BMIKUDK1y96UR54wvLCqXwAZgDKZM2xxEUMA//oEOaxV4tFoCRlDFwT0oZpyTcOgZfYzwIaM= 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=Amg53dRb; arc=none smtp.client-ip=115.124.30.118 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="Amg53dRb" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1776247525; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=siihScA3aZpqcwTKenkHHbymWnhF4GwJHnW9Do+vUPQ=; b=Amg53dRbkWwX7gIMNO4W87MQKrdNAIhszml+R33QtWTeUDSTHsPt2QzNlFwLEMYUojKxfqJlPMdgzT4rw+2m5DPr1LNzitzPcipYQf6ZeH4n4GGnE0hmKOf+70CQehqf72FvDN4DxXe1ZOBKpx6qPLJLbm2iPkDpeWN/lxE7K+k= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R101e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037009110;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---0X14KnF8_1776247524; Received: from 30.74.144.121(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X14KnF8_1776247524 cluster:ay36) by smtp.aliyun-inc.com; Wed, 15 Apr 2026 18:05:25 +0800 Message-ID: <1a3cb6b2-94e0-4268-8cd9-1f9a9deb6c6b@linux.alibaba.com> Date: Wed, 15 Apr 2026 18:05:24 +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: "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: <2d138a3f-0006-4a01-852a-4570d7ba781d@linux.alibaba.com> From: Baolin Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 4/15/26 5:54 PM, David Hildenbrand (Arm) wrote: >>>> As I mentioned, the original logic has several issues for anonymous >>>> shmem: >>>> >>>> 1. Whether anonymous shmem supports large folios can be dynamically >>>> configured via sysfs interfaces, so mapping_set_large_folios() set >>>> during initialization cannot accurately reflect whether anonymous shmem >>>> actually supports large folios. >>> >>> Well, the mapping does support large folios, just the folio allocations >>> are currently disable. >>> >>> It feels cleaner to say "there might be large folios in this mapping" >>> than saying "there are no large folios in the mapping as the mapping >>> does not support it", no? >> >> 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? > > [...] > >>> What if we say: >>> >>> shmem that *will never have*/*does never allow* large folios never sets >>> mapping_set_large_folios(). >>> >>> shmem that *might* have large folios (in the past, now, or in the >>> future) sets mapping_set_large_folios(). >> >> 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);