From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.migadu.com (out-134.mta1.migadu.com [95.215.58.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 411AC334374 for ; Fri, 28 Aug 2026 04:47:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.134 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787892462; cv=none; b=s2tHfDPXzeX8P9wnOJTHg4pRX34Yg7u9/ZQLENEzd48GF9Iie2HxoVMZapEEN/VIkcKRIy0bZQ27lLAepEfyW2NqEfJJeFoYrvwVXtwzL5ObTljfrvUfj8XVAr8s8jH0wbB/6PAeErMJ648jnpjFL7g/5IepMdQAs8jyWLUVifY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787892462; c=relaxed/simple; bh=mOPeMmcWI99dgCmtPzUV5tpD1eXN6gK8SASB4LmC0O0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=T/GXHBYtPxnnz1mZYJgbiu4OnpjHcUWVqKMWRcuxTEPgm2HpV8xwbE7epGuCPZihD1GFggZ81nNPvxlwKZFuu1DVIiZf06u4GAdMma4psALMF8w032/32IE65mQEm+j49f8QpaDtzA+pcJck+awIVzVgksl/NzA0KvqpOKIssQg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=O8l0sqUH; arc=none smtp.client-ip=95.215.58.134 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="O8l0sqUH" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=mOPeMmcWI99dgCmtPzUV5tpD1eXN6gK8SASB4LmC0O0=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1787892457; v=1; x=1788497257; b=O8l0sqUHasUayzeZQ0pzSC+4EFkh8Ye9ji62pFuD9I3Ln+EdcoB8xVYXMFmTjUj5mGTng465 zYp99+ybkZBJVL+no9nZ6qIJnOpqrqX4FpTTkUOLOiSJ1WaiJVwpUQ+5R8lxDFT+V77vzmZ6wnE K2xfAxf1CRD23rxUW7SOlUN0= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id 026258ee24c5dde1; Fri, 28 Aug 2026 04:47:26 +0000 X-Mizu-Trace-ID: 026258ee24c5dde1 X-Migadu-Flow: FLOW_OUT Message-ID: Date: Fri, 28 Aug 2026 12:47:13 +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)" Cc: linux-mm@kvack.org, Nico Pache , David Hildenbrand , Barry Song , Baolin Wang , linux-kernel@vger.kernel.org, Jason Gunthorpe , Peter Xu , Usama Arif , Dev Jain , Ryan Roberts , "Liam R. Howlett" , Cedric Le Goater , Saravanan D , stable@vger.kernel.org, Andrew Morton , Zi Yan References: <20260827-hugepfn-allowable-orders-v1-1-94819c8807c8@kernel.org> Content-Language: en-US From: Lance Yang 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 2026/8/28 03:55, 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) > --- Cool! Tested-by: Lance Yang