From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-131.freemail.mail.aliyun.com (out30-131.freemail.mail.aliyun.com [115.124.30.131]) (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 049813CB578; Mon, 31 Aug 2026 08:15:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788164157; cv=none; b=KvjODD+7qk7UMkZWzTT8o2MK9/+GrQx+ebTjZfIilVpRTS4Qc7uhh1KKIWntRhb/1NZgcI1844QYT6p1DL0oXNksVFRg41hDu7MpOie0PZ8ifFW2nw9flCV86GSyFHgzcMW82beBSJJHvpzDMOaTaleKr+t3lTa8DeRkG0uG3sU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788164157; c=relaxed/simple; bh=dO1PhbbuapCDdecX8FQLDCFikf/EZ4QABFv1142fTGk=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=uDysd4J/rnwCBb+QUlaycqvwjZGnmh13drX+Wcr6Ufw5IVim4PJqbl+lG8P4pOusBh67qn/1PiQpr1cFdJ4t/1XxR+sLSzK1EVFHJmq7vsKhjy3P5b3MN1GSILO2ZO+jZs54s/nWFgj0bM9qWQa6CiBdSBVT+Zhw8ZA9m/27ZMg= 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=YhcOYYWh; arc=none smtp.client-ip=115.124.30.131 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="YhcOYYWh" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1788164151; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=tt0yHsbfJEZ1+ZZbrMLoRaILCdqS9+900vtSCcW9og4=; b=YhcOYYWhhUoS/qMw/h4airDhg5iWAPRj31tZn884Okb/7d9P2ploVnwHmeVK+KCySkQ2wco+ufh3AEkQtFZBeBx3BUtBH/4nd0e7lYRe8JVjpW7A49xTtPlKWfSHGZ50EwFxCHhJ5Cl/nhza5oCcsANCNH09HzIUyJH/QdDixM8= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R681e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037033178;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=18;SR=0;TI=SMTPD_---0X9v1.h._1788164149; Received: from 30.74.144.115(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X9v1.h._1788164149 cluster:ay36) by smtp.aliyun-inc.com; Mon, 31 Aug 2026 16:15:49 +0800 Message-ID: <80b86bdb-9ef7-4eb8-95db-695fdae551d6@linux.alibaba.com> Date: Mon, 31 Aug 2026 16:15:48 +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] mm/huge_memory: bypass THP tuneables for huge pfnmap mappings To: "Lorenzo Stoakes (ARM)" , Andrew Morton , David Hildenbrand , Zi Yan , "Liam R. Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Usama Arif , Peter Xu , Jason Gunthorpe Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Cedric Le Goater , Saravanan D , stable@vger.kernel.org References: <20260827-hugepfn-allowable-orders-v1-1-94819c8807c8@kernel.org> From: Baolin Wang In-Reply-To: <20260827-hugepfn-allowable-orders-v1-1-94819c8807c8@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 8/28/26 3:55 AM, Lorenzo Stoakes (ARM) wrote: > The sysfs THP tuneables at /sys/kernel/mm/transparent_huge_pages/ rather > confusingly only control the behaviour of THP in some instances. > > They are not applicable to MADV_COLLAPSE operations, nor to DAX mappings. > > Long-term, THP is predicated upon compaction being able to obtain large > folios to populate THP ranges. > > However, vm_normal_folio() returns NULL for PFN map mappings, thus their > reference count is maintained by the driver, not core mm. > > As a consequence, the folios are not subject to reclaim nor compaction, so > are not truly part of the THP mechanism at all. > > However, since commit 5dd40721f147 ("mm: allow THP orders for PFNMAPs") > introduced the ability to establish huge PFN maps, they have been subject > to THP tuneables. > > This is incorrect - if a huge PFN map is available (defined by > vma->vm_ops->huge_fault being non-NULL for a VMA_PFNMAP_BIT VMA), then it > should be mapped huge upon fault-in. > > Correct this by explicitly checking for this while ensuring that smaps > continues to accurately report THPeligible statistics. > > While here, abstract the entire file-backed THP check in > vma_can_map_huge_file(), with sensible separation of logic into helper > functions. > > Note that drm_gem_shmem_mmap() and panthor_gem_mmap() establish huge PFN > maps of shmem folios, however they are marked unevictable in > drm_gem_get_pages(), and in any case would fail the reference check in > __remove_mapping() even if they weren't. > > Failing to map huge PFN maps has resulted in significant real-world > performance degradation, see links for details. > > Reported-by: Cedric Le Goater > Closes: https://lore.kernel.org/linux-mm/20260805055544.1568534-1-clg@redhat.com/ > Reported-by: Saravanan D > Closes: https://lore.kernel.org/linux-mm/20260821070520.25759-1-saravanand@crusoe.ai/ > Fixes: 5dd40721f147 ("mm: allow THP orders for PFNMAPs") > Cc: stable@vger.kernel.org > Signed-off-by: Lorenzo Stoakes (ARM) > --- LGTM. Logic looks clearer now. Thanks. Reviewed-by: Baolin Wang