[{"id":3681821,"web_url":"http://patchwork.ozlabs.org/comment/3681821/","msgid":"<0fe62163-cdfd-47e4-bc88-df7a69dc5a6d@kernel.org>","date":"2026-04-24T07:33:45","subject":"Re: [PATCH v6 4/7] mm/sparse-vmemmap: Fix DAX vmemmap accounting with\n optimization","submitter":{"id":92023,"url":"http://patchwork.ozlabs.org/api/people/92023/","name":"David Hildenbrand (Arm)","email":"david@kernel.org"},"content":"On 4/24/26 04:55, Muchun Song wrote:\n> When vmemmap optimization is enabled for DAX, the nr_memmap_pages\n> counter in /proc/vmstat is incorrect. The current code always accounts\n> for the full, non-optimized vmemmap size, but vmemmap optimization\n> reduces the actual number of vmemmap pages by reusing tail pages. This\n> causes the system to overcount vmemmap usage, leading to inaccurate\n> page statistics in /proc/vmstat.\n> \n> Fix this by introducing section_vmemmap_pages(), which returns the exact\n> vmemmap page count for a given pfn range based on whether optimization\n> is in effect.\n> \n> Fixes: 15995a352474 (\"mm: report per-page metadata information\")\n> Cc: stable@vger.kernel.org\n> Signed-off-by: Muchun Song \n> Acked-by: Mike Rapoport (Microsoft) \n> Acked-by: Oscar Salvador \n> ---\n> mm/sparse-vmemmap.c | 31 +++++++++++++++++++++++++++----\n> 1 file changed, 27 insertions(+), 4 deletions(-)\n> \n> diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c\n> index 3340f6d30b01..2e642c5ff3f2 100644\n> --- a/mm/sparse-vmemmap.c\n> +++ b/mm/sparse-vmemmap.c\n> @@ -652,6 +652,28 @@ void offline_mem_sections(unsigned long start_pfn, unsigned long end_pfn)\n> \t}\n> }\n> \n> +static int __meminit section_nr_vmemmap_pages(unsigned long pfn, unsigned long nr_pages,\n> +\t\tstruct vmem_altmap *altmap, struct dev_pagemap *pgmap)\n> +{\n> +\tconst unsigned int order = pgmap ? pgmap->vmemmap_shift : 0;\n> +\tconst unsigned long pages_per_compound = 1UL << order;\n> +\n> +\tVM_WARN_ON_ONCE(!IS_ALIGNED(pfn | nr_pages,\n> +\t\t\t\t min(pages_per_compound, PAGES_PER_SECTION)));\n\nFWIW, I though the right thing to do here would be:\n\n\tVM_WARN_ON_ONCE(!IS_ALIGNED(pfn | nr_pages, pages_per_compound);\n\tVM_WARN_ON_ONCE(!IS_ALIGNED(pfn | nr_pages, PAGES_PER_SUBSECTION);\n\nI don't really see how PAGES_PER_SECTION make sense given that\nPAGES_PER_SUBSECTION are the smallest granularity we allow adding/removing.\n\nAlso, the \"min()\" implies that there is a connection between both properties,\nbut there isn't to that degree.\n\nIf order == 0, then you'd only ever check alignment for ... 1, not\nPAGES_PER_SUBSECTION, which already looks weird.\n\nSo you really want to check \"max(pages_per_compound, PAGES_PER_SUBSECTION)\", but\njust having two statements is clearer.\n\nOr am I getting something very wrong here? :)","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=ET2IVhVP;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.ozlabs.org\n (client-ip=2404:9400:21b9:f100::1; helo=lists.ozlabs.org;\n envelope-from=linuxppc-dev+bounces-20042-incoming=patchwork.ozlabs.org@lists.ozlabs.org;\n receiver=patchwork.ozlabs.org)","lists.ozlabs.org;\n arc=none smtp.remote-ip=172.105.4.254","lists.ozlabs.org;\n dmarc=pass (p=quarantine dis=none) header.from=kernel.org","lists.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=ET2IVhVP;\n\tdkim-atps=neutral","lists.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org\n (client-ip=172.105.4.254; helo=tor.source.kernel.org;\n envelope-from=david@kernel.org; receiver=lists.ozlabs.org)"],"Received":["from lists.ozlabs.org (lists.ozlabs.org\n [IPv6:2404:9400:21b9:f100::1])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1 raw public key)\n server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g24TT1SyJz1yDD\n\tfor ; Fri, 24 Apr 2026 17:34:04 +1000 (AEST)","from boromir.ozlabs.org (localhost [127.0.0.1])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 4g24TR2sQWz2xwH;\n\tFri, 24 Apr 2026 17:34:03 +1000 (AEST)","from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 4g24TH6XCxz2xfR\n\tfor ; Fri, 24 Apr 2026 17:33:55 +1000 (AEST)","from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])\n\tby tor.source.kernel.org (Postfix) with ESMTP id 06B366001A;\n\tFri, 24 Apr 2026 07:33:53 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 4E265C19425;\n\tFri, 24 Apr 2026 07:33:47 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1777016043;\n\tcv=none;\n b=d+wmVD7EzFMqZsX3/jEvdFtmYPCQaLgecoIavA024zGdG2utjymqg0ZlmS9dZqOMHEyrgQfPzKadZvtQ1uVKccGIj6NXjGvz+hBZ3wcKYFVufjBYN96Kt6kgOjypalyuDx+cR+BWBzqhqGQs06b+1NjJbldX1jrf9EDIpqWF9e2UfQtFwQDH4iSBY4skwaqmpApIl3Yl2zWZ5NjawdllIDqGGJvXDuD5dyBHDTxveS6Rfnpupammm0BXlnHuEw/KIg+8ZJYuD6EL5z0wCFwSbhqXFy5zVHiUQNIcoKsxUxKPwBxZFPrZwrIzyoDaUN/x1Agro2kd6LjqCy5vtXQ/+Q==","ARC-Message-Signature":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707;\n\tt=1777016043; c=relaxed/relaxed;\n\tbh=i3emymLQKMW5KNMhf0/v5WxkXv+ccDytIAO46/7sqmQ=;\n\th=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:\n\t In-Reply-To:Content-Type;\n b=GXfHBuE+j/Ziru6iY6NVAQxUIuTDO8Qh//7mmbEwHU7nqXh5PMD7Ulle0TBVZHj2PpB4tLmOiElVLdORcn/3+9dUFOsAsa/MRELoMZkQUmC0E/dnfCd4cEtv0EaO2OeW/mWspsnnJ1gCPpadZLYcqCYX57xfsBfaDB89gZHNOgMcIVDnmR64JB3PGzJUKpZK/ml7ogTU2BNef1aXURSfIHKB+IMKYQbOk2Y3mZuIswDnAf+ZfMST3KTOlKpQOiDAQ2prlxxLHbte//emkeB9rDj/6yq0PzopL1tqol+nbv14vKxkKdOie0fcf8FOYEGS44mwF6uA4nqhTQS/6HqJCw==","ARC-Authentication-Results":"i=1; lists.ozlabs.org;\n dmarc=pass (p=quarantine dis=none) header.from=kernel.org;\n dkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=ET2IVhVP; dkim-atps=neutral;\n spf=pass (client-ip=172.105.4.254; helo=tor.source.kernel.org;\n envelope-from=david@kernel.org;\n receiver=lists.ozlabs.org) smtp.mailfrom=kernel.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1777016032;\n\tbh=FWUCIjlRnfU0ETPJAkdUekHGrm29nbNvT4ou3u2ZJrI=;\n\th=Date:Subject:To:Cc:References:From:In-Reply-To:From;\n\tb=ET2IVhVPW1Je/rflovdV0szP2Nft7DLDtK4Cjt8gOa3tlrF0PYvVAsdr0AtKcI2nw\n\t Nq+tRJktHRoOnrRgLjk5Kv3ysZ2GmBvgxsuvvvVS0TTGEE7lrAaIzb149j1fee4kf4\n\t suHj+w2LF9Z9O8b/zefIcUsWF1YP8BPRUf94MHKp5vYpn5HZl+5iwfqHVhO9BKX13G\n\t TokYxhGt++juL6hzDh2Tme7OW4r63MYtWKGLTq0MG3pu3l2XBFHr7Tbi8btjUy7Nuu\n\t Gn8N/LHbYUCbRCqqvn8DuTdr5+LOL4DK+dRWxwDt3pTs3GTdLY10KD3DuG7COGtHP1\n\t QTWokFnUqoNtw==","Message-ID":"<0fe62163-cdfd-47e4-bc88-df7a69dc5a6d@kernel.org>","Date":"Fri, 24 Apr 2026 09:33:45 +0200","X-Mailing-List":"linuxppc-dev@lists.ozlabs.org","List-Id":"","List-Help":"","List-Owner":"","List-Post":"","List-Archive":",\n ","List-Subscribe":",\n ,\n ","List-Unsubscribe":"","Precedence":"list","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH v6 4/7] mm/sparse-vmemmap: Fix DAX vmemmap accounting with\n optimization","To":"Muchun Song ,\n Andrew Morton ,\n Muchun Song , Oscar Salvador ,\n Michael Ellerman ,\n Madhavan Srinivasan ","Cc":"Lorenzo Stoakes ,\n \"Liam R . Howlett\" ,\n Vlastimil Babka , Mike Rapoport ,\n Suren Baghdasaryan , Michal Hocko ,\n Nicholas Piggin , Christophe Leroy ,\n aneesh.kumar@linux.ibm.com, joao.m.martins@oracle.com, linux-mm@kvack.org,\n linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,\n stable@vger.kernel.org","References":"<20260424025547.3806072-1-songmuchun@bytedance.com>\n <20260424025547.3806072-5-songmuchun@bytedance.com>","From":"\"David Hildenbrand (Arm)\" ","Content-Language":"en-US","Autocrypt":"addr=david@kernel.org; keydata=\n xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ\n dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL\n QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp\n XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK\n Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9\n PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt\n WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc\n UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv\n jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb\n B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzS5EYXZpZCBIaWxk\n ZW5icmFuZCAoQ3VycmVudCkgPGRhdmlkQGtlcm5lbC5vcmc+wsGQBBMBCAA6AhsDBQkmWAik\n AgsJBBUKCQgCFgICHgUCF4AWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaYJt/AIZAQAKCRBN\n 3hD3AP+DWriiD/9BLGEKG+N8L2AXhikJg6YmXom9ytRwPqDgpHpVg2xdhopoWdMRXjzOrIKD\n g4LSnFaKneQD0hZhoArEeamG5tyo32xoRsPwkbpIzL0OKSZ8G6mVbFGpjmyDLQCAxteXCLXz\n ZI0VbsuJKelYnKcXWOIndOrNRvE5eoOfTt2XfBnAapxMYY2IsV+qaUXlO63GgfIOg8RBaj7x\n 3NxkI3rV0SHhI4GU9K6jCvGghxeS1QX6L/XI9mfAYaIwGy5B68kF26piAVYv/QZDEVIpo3t7\n /fjSpxKT8plJH6rhhR0epy8dWRHk3qT5tk2P85twasdloWtkMZ7FsCJRKWscm1BLpsDn6EQ4\n jeMHECiY9kGKKi8dQpv3FRyo2QApZ49NNDbwcR0ZndK0XFo15iH708H5Qja/8TuXCwnPWAcJ\n DQoNIDFyaxe26Rx3ZwUkRALa3iPcVjE0//TrQ4KnFf+lMBSrS33xDDBfevW9+Dk6IISmDH1R\n HFq2jpkN+FX/PE8eVhV68B2DsAPZ5rUwyCKUXPTJ/irrCCmAAb5Jpv11S7hUSpqtM/6oVESC\n 3z/7CzrVtRODzLtNgV4r5EI+wAv/3PgJLlMwgJM90Fb3CB2IgbxhjvmB1WNdvXACVydx55V7\n LPPKodSTF29rlnQAf9HLgCphuuSrrPn5VQDaYZl4N/7zc2wcWM7BTQRVy5+RARAA59fefSDR\n 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt\n VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk\n /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy\n iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ\n 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21\n zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg\n azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY\n FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D\n sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO\n 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e\n EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts\n IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC\n 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV\n Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS\n sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx\n yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9\n 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg\n r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ\n 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ\n CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY\n qIws/H2t","In-Reply-To":"<20260424025547.3806072-5-songmuchun@bytedance.com>","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"7bit","X-Spam-Status":"No, score=-0.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,\n\tDKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS\n\tautolearn=disabled version=4.0.1 OzLabs 8","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on lists.ozlabs.org"}},{"id":3681836,"web_url":"http://patchwork.ozlabs.org/comment/3681836/","msgid":"<5A4644D9-B64E-4AD9-9D9A-B3DAB84CB827@linux.dev>","date":"2026-04-24T07:48:44","subject":"Re: [PATCH v6 4/7] mm/sparse-vmemmap: Fix DAX vmemmap accounting with\n optimization","submitter":{"id":84878,"url":"http://patchwork.ozlabs.org/api/people/84878/","name":"Muchun Song","email":"muchun.song@linux.dev"},"content":"> On Apr 24, 2026, at 15:33, David Hildenbrand (Arm) wrote:\n> \n> On 4/24/26 04:55, Muchun Song wrote:\n>> When vmemmap optimization is enabled for DAX, the nr_memmap_pages\n>> counter in /proc/vmstat is incorrect. The current code always accounts\n>> for the full, non-optimized vmemmap size, but vmemmap optimization\n>> reduces the actual number of vmemmap pages by reusing tail pages. This\n>> causes the system to overcount vmemmap usage, leading to inaccurate\n>> page statistics in /proc/vmstat.\n>> \n>> Fix this by introducing section_vmemmap_pages(), which returns the exact\n>> vmemmap page count for a given pfn range based on whether optimization\n>> is in effect.\n>> \n>> Fixes: 15995a352474 (\"mm: report per-page metadata information\")\n>> Cc: stable@vger.kernel.org\n>> Signed-off-by: Muchun Song \n>> Acked-by: Mike Rapoport (Microsoft) \n>> Acked-by: Oscar Salvador \n>> ---\n>> mm/sparse-vmemmap.c | 31 +++++++++++++++++++++++++++----\n>> 1 file changed, 27 insertions(+), 4 deletions(-)\n>> \n>> diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c\n>> index 3340f6d30b01..2e642c5ff3f2 100644\n>> --- a/mm/sparse-vmemmap.c\n>> +++ b/mm/sparse-vmemmap.c\n>> @@ -652,6 +652,28 @@ void offline_mem_sections(unsigned long start_pfn, unsigned long end_pfn)\n>> }\n>> }\n>> \n>> +static int __meminit section_nr_vmemmap_pages(unsigned long pfn, unsigned long nr_pages,\n>> + \t\tstruct vmem_altmap *altmap, struct dev_pagemap *pgmap)\n>> +{\n>> + \tconst unsigned int order = pgmap ? pgmap->vmemmap_shift : 0;\n>> + \tconst unsigned long pages_per_compound = 1UL << order;\n>> +\n>> + \tVM_WARN_ON_ONCE(!IS_ALIGNED(pfn | nr_pages,\n>> + \t\t\t\t min(pages_per_compound, PAGES_PER_SECTION)));\n> \n> FWIW, I though the right thing to do here would be:\n> \n> VM_WARN_ON_ONCE(!IS_ALIGNED(pfn | nr_pages, pages_per_compound);\n> VM_WARN_ON_ONCE(!IS_ALIGNED(pfn | nr_pages, PAGES_PER_SUBSECTION);\n> \n> I don't really see how PAGES_PER_SECTION make sense given that\n> PAGES_PER_SUBSECTION are the smallest granularity we allow adding/removing.\n> \n> Also, the \"min()\" implies that there is a connection between both properties,\n> but there isn't to that degree.\n> \n> If order == 0, then you'd only ever check alignment for ... 1, not\n> PAGES_PER_SUBSECTION, which already looks weird.\n> \n> So you really want to check \"max(pages_per_compound, PAGES_PER_SUBSECTION)\", but\n> just having two statements is clearer.\n> \n> Or am I getting something very wrong here? :)\n> \n\nYou are absolutely right. I misread it earlier. I mistakenly read\nPAGES_PER_SUBSECTION as PAGES_PER_SECTION, which is why I still used\nPAGES_PER_SECTION in v5. That was my mistake and obviously not what\nyou originally meant.\n\nI completely agree with your suggestion to use two statements here,\nas it makes the alignment requirements much clearer. I'll fix this in\nthe next version. Thanks for pointing this out!\n\nMuchun,\nThanks.\n\n> \n> -- \n> Cheers,\n> \n> David","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256\n header.s=key1 header.b=f5sWadWI;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.ozlabs.org\n (client-ip=2404:9400:21b9:f100::1; helo=lists.ozlabs.org;\n envelope-from=linuxppc-dev+bounces-20044-incoming=patchwork.ozlabs.org@lists.ozlabs.org;\n receiver=patchwork.ozlabs.org)","lists.ozlabs.org;\n arc=none smtp.remote-ip=95.215.58.170","lists.ozlabs.org;\n dmarc=pass (p=none dis=none) header.from=linux.dev","lists.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256\n header.s=key1 header.b=f5sWadWI;\n\tdkim-atps=neutral","lists.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=linux.dev\n (client-ip=95.215.58.170; helo=out-170.mta1.migadu.com;\n envelope-from=muchun.song@linux.dev; receiver=lists.ozlabs.org)"],"Received":["from lists.ozlabs.org (lists.ozlabs.org\n [IPv6:2404:9400:21b9:f100::1])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g24t12HSyz1yD5\n\tfor ; Fri, 24 Apr 2026 17:51:52 +1000 (AEST)","from boromir.ozlabs.org (localhost [127.0.0.1])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 4g24t02M8Vz2yFm;\n\tFri, 24 Apr 2026 17:51:52 +1000 (AEST)","from out-170.mta1.migadu.com (out-170.mta1.migadu.com\n [95.215.58.170])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 4g24sw3HZdz2xly\n\tfor ; Fri, 24 Apr 2026 17:51:46 +1000 (AEST)"],"ARC-Seal":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1777017112;\n\tcv=none;\n b=I1uy7KPhJekxv3kfBJ2M3YWNO4QBFpZwthlsmNWZtPqhK385A6q7b9XDm0ocJz+BnxJH3ADg62e4LIolXVDtDn6AhuTTAkawHUv9K88hugFYQKYe5fSifd2ABN34yYf0bOPBxs5eC5RLNd1tzQNKX3xrnqoO/Klr9WzGJNyJwOETvj5hVXL/Dk80FoWUo990s/b+72b/2oGLvbDwJbPbyNN5Cv3n3jPzmoPr1HL8iTzyvm7bhf3FhTsQAVPiHmVZeXaWhXUXya3KdG+ecXiiT1R7hZGOcfBjOCj/jpij0Hq16UmlHiLBCg6/aDSD3G7N92X1SDPnw3+KyXkeEDfTDw==","ARC-Message-Signature":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707;\n\tt=1777017112; c=relaxed/relaxed;\n\tbh=/ORSaWnko0V3NhVqidFGTv7S6AWqSkqSLorMuOfpODA=;\n\th=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:\n\t Message-Id:References:To;\n b=jrebVs8vOhHcH5l4eDJ1R72dUCQ4UK/qpiaXG2Fb80RFzPcLoITd6or/kMk/Esj2a3j8TTaKMRA5xOjgf6Q80MLdmUu2NQr6aGajlLGppNXz+rZ4CSnWBgEt/xdwhqRTODvi6Y/XVk34FIvE4KBIW9e8VG1hLdZzijh93q8Zku1n/QQBNE4Tczwkra4PU63vJAJDI0bAslKNE1bHRHppEryj+9sPagZv1xCB1VQPG9sd8zcZbgp4PHypPiUa4Qml/iBlUfVCHjuZRlCtPLerf3z80XyDISSaUFViKfzgSPfcALuP/KmjkN/q+iVoAEOy3ktLfLxKl9avJ5jDYGriXA==","ARC-Authentication-Results":"i=1; lists.ozlabs.org;\n dmarc=pass (p=none dis=none) header.from=linux.dev; dkim=pass (1024-bit key;\n unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256\n header.s=key1 header.b=f5sWadWI; dkim-atps=neutral;\n spf=pass (client-ip=95.215.58.170; helo=out-170.mta1.migadu.com;\n envelope-from=muchun.song@linux.dev;\n receiver=lists.ozlabs.org) smtp.mailfrom=linux.dev","Content-Type":"text/plain;\n\tcharset=us-ascii","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1;\n\tt=1777017086;\n\th=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n\t to:to:cc:cc:mime-version:mime-version:content-type:content-type:\n\t content-transfer-encoding:content-transfer-encoding:\n\t in-reply-to:in-reply-to:references:references;\n\tbh=/ORSaWnko0V3NhVqidFGTv7S6AWqSkqSLorMuOfpODA=;\n\tb=f5sWadWIcXFWMoPuLXqfAVQq8XtQDNfCfsvXrl+tyhRViG3SQIamnGMCotuewbABJ9cFH4\n\tPYhz/HibwXyamvirz+mWtj2C3RPJ/RNlVHmjxhhppl13+g7APOW6R5fSkAUQgJxqYQ7tdZ\n\tDvCm6GbEn5PGd64kYmFnP3vBYTawe0o=","X-Mailing-List":"linuxppc-dev@lists.ozlabs.org","List-Id":"","List-Help":"","List-Owner":"","List-Post":"","List-Archive":",\n ","List-Subscribe":",\n ,\n ","List-Unsubscribe":"","Precedence":"list","Mime-Version":"1.0 (Mac OS X Mail 16.0 \\(3864.500.181\\))","Subject":"Re: [PATCH v6 4/7] mm/sparse-vmemmap: Fix DAX vmemmap accounting with\n optimization","X-Report-Abuse":"Please report any abuse attempt to abuse@migadu.com and\n include these headers.","From":"Muchun Song ","In-Reply-To":"<0fe62163-cdfd-47e4-bc88-df7a69dc5a6d@kernel.org>","Date":"Fri, 24 Apr 2026 15:48:44 +0800","Cc":"Muchun Song ,\n Andrew Morton ,\n Oscar Salvador ,\n Michael Ellerman ,\n Madhavan Srinivasan ,\n Lorenzo Stoakes ,\n \"Liam R . Howlett\" ,\n Vlastimil Babka ,\n Mike Rapoport ,\n Suren Baghdasaryan ,\n Michal Hocko ,\n Nicholas Piggin ,\n Christophe Leroy ,\n aneesh.kumar@linux.ibm.com,\n joao.m.martins@oracle.com,\n linux-mm@kvack.org,\n linuxppc-dev@lists.ozlabs.org,\n linux-kernel@vger.kernel.org,\n stable@vger.kernel.org","Content-Transfer-Encoding":"quoted-printable","Message-Id":"<5A4644D9-B64E-4AD9-9D9A-B3DAB84CB827@linux.dev>","References":"<20260424025547.3806072-1-songmuchun@bytedance.com>\n <20260424025547.3806072-5-songmuchun@bytedance.com>\n <0fe62163-cdfd-47e4-bc88-df7a69dc5a6d@kernel.org>","To":"\"David Hildenbrand (Arm)\" ","X-Migadu-Flow":"FLOW_OUT","X-Spam-Status":"No, score=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID,\n\tDKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS\n\tautolearn=disabled version=4.0.1 OzLabs 8","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on lists.ozlabs.org"}}]