From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 2609D2C3768 for ; Thu, 6 Aug 2026 14:42:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786027345; cv=none; b=KRKGIg09hkLJ7SnnjydsrLcAyIDalsHuh2WjwxUop5CTWDh9EETPL+eXf+aB4PY34YR70vN4RFxYLALrH8RjobUsL3fxM3Xs+2nQWjKtCB7r9IWa4PmqpYqkU+B3GjkTV6oeVm/AOqJ5wGHXhlGr+g49Bq7sypMxf/NhFFqiRDs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786027345; c=relaxed/simple; bh=AiKZOoqsdhscH3X5tTSOs7l/4l41JC6Fbu7L1hSJE/4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=rmw+Yu7gTi/PqigIOYFQ0t2NqB0zWE8eJluWZ5fl9ZdJF9RGgXV4Zucq8YBBOA32kQMCJlDEnZasiUApt13Ta/sStLdehH2T7cMb8V7vcoyFgsOsQfsvqIbxrmWwbmj8m/VJtzo4cN4A2EU7IvGKt3CBZKenPnhLVef+5HtIzCA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=g+Xvb6jE; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=IkuNVtRc; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="g+Xvb6jE"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="IkuNVtRc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1786027343; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=Y8GfkU9TTPckwMBwt43hPKDhEB5BQFXtyP1DfYP8FF4=; b=g+Xvb6jEBgLb/YSotnx+TtMYe+ViVMs8kL883xfeyPAsXS2E+vdabYkuoTh9jC9xxT3J/Y GbnFagxM/smo6jnV12a/Db9aCfJU/jp+UY6h5jJ3SxlkfF1QGtlS8yCV7D/p3M1sKyyPWA G4+qR0QRMavA+pVAr45wPxbLCBTwlHQ= Received: from mail-ej1-f70.google.com (mail-ej1-f70.google.com [209.85.218.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-682-6OTaiGnIN1yE_RyxQtOVOQ-1; Thu, 06 Aug 2026 10:42:22 -0400 X-MC-Unique: 6OTaiGnIN1yE_RyxQtOVOQ-1 X-Mimecast-MFC-AGG-ID: 6OTaiGnIN1yE_RyxQtOVOQ_1786027341 Received: by mail-ej1-f70.google.com with SMTP id a640c23a62f3a-c15fed5653eso170832266b.2 for ; Thu, 06 Aug 2026 07:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1786027341; x=1786632141; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:from:references:cc:to:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=Y8GfkU9TTPckwMBwt43hPKDhEB5BQFXtyP1DfYP8FF4=; b=IkuNVtRcgcvEMxhC+7f/uCs/CWTyaTD9qPPc+nJaYwpNq6xaiHlOzT1EVBJEIC/oFi R+nB9CY7i07JQb6wWPSoNUTORXFIqriZtr03UWnF4Sz2rlyVQLIApWyvTDUhQaJLxWoA GTNlEJqhPutmF1rA0VR7dGwuj5FLMYRwi2pvjExp5NkK4n9RVEdrvuBOQIBvo2bFlSoR ySq2Qc2J1sxKEaAh2+dsHL4tuM6Uj/iMk4uCOI9HyiO+ILH9gOSIDDZu2P73f+sbPrXS BkvzKvmT5aKc4sf26RRlx8krP/R78un594x4BgICnXoEJJ3RzQQ+U2I2YftVO0VVn8kj t/RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786027341; x=1786632141; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:from:references:cc:to:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=Y8GfkU9TTPckwMBwt43hPKDhEB5BQFXtyP1DfYP8FF4=; b=Pkk90RCvwT3+D7M1L07XkiY5BB7KfAJ/1obBEuVmLdROitC9rWevVcStxA9l1QOSiR Xr5UsqTrbzfIv9u8yE9UzGY50Z5zJhIPqPF4GkHcX606GhAe1ABtm29C8dg7+PJID7w9 fDCBrW5bH/wWwRmgLRK+olxXOeiTQmvvCY/psCd2OaUwZF3xhcEkpiHhB5xdbCPfzxeU 4+YDHkUOKAHKrFSRuAGfvJMK8hq1U/XVsO+rbG3RDNMGUz1VCe9uvCYLASLobPq8eo/f jVA42cTYBJrDmxLZg15ejafJxJULz3B+eJ305N3eS4veiVBA7I3akVrtH6XCgaBuCe2U 9YEQ== X-Forwarded-Encrypted: i=1; AHgh+RpsH1KhQ7lqqTKkqCAN1HtXc2LAogdf/bN6q8ewj8n+slBWTfxle2LYuWTfz5F0jlkkgbeIWRZtONgYFgA=@vger.kernel.org X-Gm-Message-State: AOJu0Yz/+BE25vQj5Kac8fI0znayPnZyGljRtpoclWrQAdT7jcEWkWbt YlCaI8hDzjqc6cb7j98xsbA7DzxO8dl7nANpc/xPZ9YyDUUqGYR1tcmroYZh7irPuUMeHMuGM8c PyvZKNpJNBcyy73mOqLVSrSxS5RtIRarjD6PHzUJV+s7uua9zBkY47CskZjht0SRRkKMVD+tvEg == X-Gm-Gg: AR+sD12ZGsBWtQyutxKdiQfjt+r9jcGyMlAT7Yj8Oh5Q8EkVJjwlJRuQD2SMAka5K1/ hlgchmBqtn8AhMkxLFKupv6mi0NkbEbaHlXfpFVr0tQ288YVen5jT85t8YyDNiOr84cR18/m0d9 pQMoDp5fiWvinrhFksNS2PnltcJzT0pElDaLJ+y5vPl4eSDoooVgQqZEwLpHqs8PxLiD+//HSqZ Caqf8/gTLyqC8wGvieEqtYjD/UacjX0LCnKzQ8RxNYrVmqIrXJ1sHwYoQnDIZI+iY4YfOfG64QC H6wc3QkET8oSmgI5OF3evnCvTFkYpzd7QGR74JIiEIo34Zew5hdOLPHPwS4GetJXc479tPXAUP8 nDpK2FKrhQ1tMFNXb5WqEjYqkOqDKjvcDDFylOe4= X-Received: by 2002:a17:906:d181:b0:c16:1a00:3feb with SMTP id a640c23a62f3a-c2073365229mr81915066b.15.1786027340791; Thu, 06 Aug 2026 07:42:20 -0700 (PDT) X-Received: by 2002:a17:906:d181:b0:c16:1a00:3feb with SMTP id a640c23a62f3a-c2073365229mr81911266b.15.1786027340246; Thu, 06 Aug 2026 07:42:20 -0700 (PDT) Received: from ?IPV6:2a01:e0a:280:24f0:576b:abc6:6396:ed4a? ([2a01:e0a:280:24f0:576b:abc6:6396:ed4a]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c20361312eesm272059666b.4.2026.08.06.07.42.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 Aug 2026 07:42:19 -0700 (PDT) Message-ID: <5b7e84f5-2007-458c-910f-7a6e1e3d3eab@redhat.com> Date: Thu, 6 Aug 2026 16:42:18 +0200 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: let special huge VMAs bypass the THP policy check To: "Lorenzo Stoakes (ARM)" , "David Hildenbrand (Arm)" Cc: Andrew Morton , linux-mm@kvack.org, Peter Xu , Alex Williamson , Jason Gunthorpe , Zi Yan , stable@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260805055544.1568534-1-clg@redhat.com> <0e52d0b4-064d-4602-8e7b-5744b05f24ea@kernel.org> From: =?UTF-8?Q?C=C3=A9dric_Le_Goater?= Content-Language: en-US, fr Autocrypt: addr=clg@redhat.com; keydata= xsFNBFu8o3UBEADP+oJVJaWm5vzZa/iLgpBAuzxSmNYhURZH+guITvSySk30YWfLYGBWQgeo 8NzNXBY3cH7JX3/a0jzmhDc0U61qFxVgrPqs1PQOjp7yRSFuDAnjtRqNvWkvlnRWLFq4+U5t yzYe4SFMjFb6Oc0xkQmaK2flmiJNnnxPttYwKBPd98WfXMmjwAv7QfwW+OL3VlTPADgzkcqj 53bfZ4VblAQrq6Ctbtu7JuUGAxSIL3XqeQlAwwLTfFGrmpY7MroE7n9Rl+hy/kuIrb/TO8n0 ZxYXvvhT7OmRKvbYuc5Jze6o7op/bJHlufY+AquYQ4dPxjPPVUT/DLiUYJ3oVBWFYNbzfOrV RxEwNuRbycttMiZWxgflsQoHF06q/2l4ttS3zsV4TDZudMq0TbCH/uJFPFsbHUN91qwwaN/+ gy1j7o6aWMz+Ib3O9dK2M/j/O/Ube95mdCqN4N/uSnDlca3YDEWrV9jO1mUS/ndOkjxa34ia 70FjwiSQAsyIwqbRO3CGmiOJqDa9qNvd2TJgAaS2WCw/TlBALjVQ7AyoPEoBPj31K74Wc4GS Rm+FSch32ei61yFu6ACdZ12i5Edt+To+hkElzjt6db/UgRUeKfzlMB7PodK7o8NBD8outJGS tsL2GRX24QvvBuusJdMiLGpNz3uqyqwzC5w0Fd34E6G94806fwARAQABzSJDw6lkcmljIExl IEdvYXRlciA8Y2xnQHJlZGhhdC5jb20+wsGRBBMBCAA7FiEEoPZlSPBIlev+awtgUaNDx8/7 7KEFAmTLlVECGwMFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQUaNDx8/77KG0eg// S0zIzTcxkrwJ/9XgdcvVTnXLVF9V4/tZPfB7sCp8rpDCEseU6O0TkOVFoGWM39sEMiQBSvyY lHrP7p7E/JYQNNLh441MfaX8RJ5Ul3btluLapm8oHp/vbHKV2IhLcpNCfAqaQKdfk8yazYhh EdxTBlzxPcu+78uE5fF4wusmtutK0JG0sAgq0mHFZX7qKG6LIbdLdaQalZ8CCFMKUhLptW71 xe+aNrn7hScBoOj2kTDRgf9CE7svmjGToJzUxgeh9mIkxAxTu7XU+8lmL28j2L5uNuDOq9vl hM30OT+pfHmyPLtLK8+GXfFDxjea5hZLF+2yolE/ATQFt9AmOmXC+YayrcO2ZvdnKExZS1o8 VUKpZgRnkwMUUReaF/mTauRQGLuS4lDcI4DrARPyLGNbvYlpmJWnGRWCDguQ/LBPpbG7djoy k3NlvoeA757c4DgCzggViqLm0Bae320qEc6z9o0X0ePqSU2f7vcuWN49Uhox5kM5L86DzjEQ RHXndoJkeL8LmHx8DM+kx4aZt0zVfCHwmKTkSTQoAQakLpLte7tWXIio9ZKhUGPv/eHxXEoS 0rOOAZ6np1U/xNR82QbF9qr9TrTVI3GtVe7Vxmff+qoSAxJiZQCo5kt0YlWwti2fFI4xvkOi V7lyhOA3+/3oRKpZYQ86Frlo61HU3r6d9wzOwU0EW7yjdQEQALyDNNMw/08/fsyWEWjfqVhW pOOrX2h+z4q0lOHkjxi/FRIRLfXeZjFfNQNLSoL8j1y2rQOs1j1g+NV3K5hrZYYcMs0xhmrZ KXAHjjDx7FW3sG3jcGjFW5Xk4olTrZwFsZVUcP8XZlArLmkAX3UyrrXEWPSBJCXxDIW1hzwp bV/nVbo/K9XBptT/wPd+RPiOTIIRptjypGY+S23HYBDND3mtfTz/uY0Jytaio9GETj+fFis6 TxFjjbZNUxKpwftu/4RimZ7qL+uM1rG1lLWc9SPtFxRQ8uLvLOUFB1AqHixBcx7LIXSKZEFU CSLB2AE4wXQkJbApye48qnZ09zc929df5gU6hjgqV9Gk1rIfHxvTsYltA1jWalySEScmr0iS YBZjw8Nbd7SxeomAxzBv2l1Fk8fPzR7M616dtb3Z3HLjyvwAwxtfGD7VnvINPbzyibbe9c6g LxYCr23c2Ry0UfFXh6UKD83d5ybqnXrEJ5n/t1+TLGCYGzF2erVYGkQrReJe8Mld3iGVldB7 JhuAU1+d88NS3aBpNF6TbGXqlXGF6Yua6n1cOY2Yb4lO/mDKgjXd3aviqlwVlodC8AwI0Sdu jWryzL5/AGEU2sIDQCHuv1QgzmKwhE58d475KdVX/3Vt5I9kTXpvEpfW18TjlFkdHGESM/Jx IqVsqvhAJkalABEBAAHCwV8EGAECAAkFAlu8o3UCGwwACgkQUaNDx8/77KEhwg//WqVopd5k 8hQb9VVdk6RQOCTfo6wHhEqgjbXQGlaxKHoXywEQBi8eULbeMQf5l4+tHJWBxswQ93IHBQjK yKyNr4FXseUI5O20XVNYDJZUrhA4yn0e/Af0IX25d94HXQ5sMTWr1qlSK6Zu79lbH3R57w9j hQm9emQEp785ui3A5U2Lqp6nWYWXz0eUZ0Tad2zC71Gg9VazU9MXyWn749s0nXbVLcLS0yop s302Gf3ZmtgfXTX/W+M25hiVRRKCH88yr6it+OMJBUndQVAA/fE9hYom6t/zqA248j0QAV/p LHH3hSirE1mv+7jpQnhMvatrwUpeXrOiEw1nHzWCqOJUZ4SY+HmGFW0YirWV2mYKoaGO2YBU wYF7O9TI3GEEgRMBIRT98fHa0NPwtlTktVISl73LpgVscdW8yg9Gc82oe8FzU1uHjU8b10lU XOMHpqDDEV9//r4ZhkKZ9C4O+YZcTFu+mvAY3GlqivBNkmYsHYSlFsbxc37E1HpTEaSWsGfA HQoPn9qrDJgsgcbBVc1gkUT6hnxShKPp4PlsZVMNjvPAnr5TEBgHkk54HQRhhwcYv1T2QumQ izDiU6iOrUzBThaMhZO3i927SG2DwWDVzZltKrCMD1aMPvb3NU8FOYRhNmIFR3fcalYr+9gD uVKe8BVz4atMOoktmt0GWTOC8P4= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 8/6/26 16:28, Lorenzo Stoakes (ARM) wrote: > On Thu, Aug 06, 2026 at 04:26:20PM +0200, David Hildenbrand (Arm) wrote: >> On 8/5/26 07:55, Cédric Le Goater wrote: >>> From: Cedric Le Goater >>> >>> The global THP sysfs policy (transparent_hugepage=never/madvise/always) >>> gates the huge fault dispatch path in __thp_vma_allowable_orders() for >>> all non-anonymous VMAs, including PFN-mapped device BARs (VM_PFNMAP). >>> >>> DAX VMAs already bypass this check via an early return: >>> >>> if (vma_is_dax(vma)) >>> return in_pf ? orders : 0; >>> >>> But "special huge" VMAs -- identified by vma_is_special_huge() -- do not >>> get this early return, even though they share the same fundamental >>> property: they map physical addresses directly into page tables and >>> involve no memory allocation, no compaction, no splitting, and no >>> reclaim. The THP policy has no meaningful effect on them. >>> >>> This matters for VFIO PCI passthrough of large-BAR devices such as >>> NVIDIA H200 NVL GPUs (256 GB BAR each). The VFIO driver registers a >>> .huge_fault handler (vfio_pci_mmap_huge_fault) that dispatches to >>> vmf_insert_pfn_pmd/pud, and QEMU's vfio_region_mmap() aligns the BAR >>> mappings for huge page table entries. Both prerequisites are met, but >>> with THP=never or THP=madvise, __thp_vma_allowable_orders() returns 0 >>> before reaching the "trust huge_fault handlers" code. >>> >>> The result: each 256 GB BAR is mapped at 4 KiB granularity -- 67 million >>> page faults per GPU instead of a few thousand PMD/PUD faults. On hosts >>> with 8 GPUs (2 TB of BAR space), this causes VM boot times to degrade >>> severely, with 99.98% of CPU time spent in the VFIO BAR mapping path. >>> >>> Configurations that trigger this: >>> - transparent_hugepage=never on the kernel command line >>> - The tuned cpu-partitioning profile (inherits network-latency, which >>> sets transparent_hugepages=never via sysfs) >>> - transparent_hugepage=madvise (the RHEL default), since VFIO VMAs >>> lack VM_HUGEPAGE and QEMU does not call madvise(MADV_HUGEPAGE) on >>> BAR mmap regions >>> >>> Extend the existing DAX early return to also cover vma_is_special_huge() >>> VMAs. This is consistent with how vma_is_special_huge() is already >>> treated for supported_orders (grouped with DAX). The mm/Kconfig TODO >>> comment "Allow to be enabled without THP" also acknowledges this >>> coupling is wrong. >>> >>> Cc: Peter Xu >>> Cc: Andrew Morton >>> Cc: Lorenzo Stoakes >>> Cc: David Hildenbrand >>> Cc: Alex Williamson >>> Cc: Jason Gunthorpe >>> Cc: Zi Yan >>> Fixes: 5dd40721f147 ("mm: allow THP orders for PFNMAPs") >>> Cc: stable@vger.kernel.org >>> Assisted-by: Claude:claude-opus-4 >>> Signed-off-by: Cedric Le Goater >>> --- >>> mm/huge_memory.c | 8 ++++++-- >>> 1 file changed, 6 insertions(+), 2 deletions(-) >>> >>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c >>> index 58cabe6af33d031e48250e21db51506bc46c97b2..6dfef5500a054f09f9ece6df8bf7a0194624350f 100644 >>> --- a/mm/huge_memory.c >>> +++ b/mm/huge_memory.c >>> @@ -139,8 +139,12 @@ unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma, >>> if (thp_disabled_by_hw() || vma_thp_disabled(vma, vm_flags, forced_collapse)) >>> return 0; >>> >>> - /* khugepaged doesn't collapse DAX vma, but page fault is fine. */ >>> - if (vma_is_dax(vma)) >>> + /* >>> + * khugepaged doesn't collapse DAX or special huge VMAs, but page >>> + * fault is fine. These map physical addresses directly — the THP >>> + * policy is irrelevant for them. >> >> emdash in a code comment? There are quite a few of these in the code in fact. >> Then I spot >> >> Assisted-by: Claude:claude-opus-4 >> >> and really have to shake my head. It's a one liner. Good enough to raise the discussion no ? > Ha, I missed that! Me too. But, you have more to add to it anyway. It should be dropped. > Well all the more reason for me to take over this patch... :) > > At least the AI is acked here (appreciate that at least Cedric). Yeah. Let's be honest. Even if I understand what is going on, Claude was faster at digging through the code and connecting the dots than I would have been on my own. The AI behemoth dropped my accent though. Cédric it should have been. I wonder why. > I think the _actual issue_ is valid at least. The huge pfn stuff did seem to > completely miss this aspect of things. It's a real problem indeed and to cover mix of workloads, it it difficult to address without a kernel patch. Cheers, C.