From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4AEEEC35274 for ; Mon, 18 Dec 2023 17:47:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DBDEE6B009A; Mon, 18 Dec 2023 12:47:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D45306B009B; Mon, 18 Dec 2023 12:47:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BBE556B009C; Mon, 18 Dec 2023 12:47:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id A79DB6B009A for ; Mon, 18 Dec 2023 12:47:25 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 7AE26140BBF for ; Mon, 18 Dec 2023 17:47:25 +0000 (UTC) X-FDA: 81580670850.17.FED4F03 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf30.hostedemail.com (Postfix) with ESMTP id 45E5680002 for ; Mon, 18 Dec 2023 17:47:23 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=aFDvNdVQ; spf=pass (imf30.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1702921643; h=from:from:sender: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:dkim-signature; bh=VXUpG+bRGJnp+OSohNJ9k3VW3RttT/l1zjhlcsHI6aY=; b=plOPS9whr3Oak1Ej4vWy4yJMPGv7jNFT2v06FqyhQmK3PUyFaM6uulKDE0Ac9+TYiyCHml QpX20Sm9R2rdHMv353BDF6/sN32qK4wv9b3xM/sccLMX+C0vl3mfIDnWTwZb+IqGGMu6fz KJLuEA3DhKhNMOHLdx7HtpUVwUobcEY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702921643; a=rsa-sha256; cv=none; b=roBT4XNJmT7rBvloZLo6CqdTMkJFJKweD9oi45P0xUlM8jrFn3zxB/oqZ/qjmiAp5Jahq1 YU8TZuLcnWciAqvAv9I6uBL1j7W6Y1gNG1rSKA8jZ9TPofoczmDubkkaPT57SmqJrQDpMv +4PV9WWBghG87mBUTNy2bGQSyTaLEtM= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=aFDvNdVQ; spf=pass (imf30.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1702921642; 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=VXUpG+bRGJnp+OSohNJ9k3VW3RttT/l1zjhlcsHI6aY=; b=aFDvNdVQwHk5oF2AwrKgfNKuzPI8bHKBwaYbg1DkX85E5qQEnBmDLUMB0aH5bkITv2kabe QbRUazaOCqWTYDGwn2Ph4ToQ5Xkh51qdW2DNjnfn76l0S94dbN50KUIlQv8vPa1RZ23ZmD sBzU8Gq8vfkxYRMzMWWRTKY8Tf/0ITg= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-691-Nal_MSInMZ6-EpVN7TfKkg-1; Mon, 18 Dec 2023 12:47:21 -0500 X-MC-Unique: Nal_MSInMZ6-EpVN7TfKkg-1 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-40c348e529fso30411105e9.2 for ; Mon, 18 Dec 2023 09:47:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702921640; x=1703526440; h=content-transfer-encoding:in-reply-to:organization:autocrypt:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=VXUpG+bRGJnp+OSohNJ9k3VW3RttT/l1zjhlcsHI6aY=; b=TWUnnTuiZ7y7CzwdQhv2qzCeC+kD8WECrCG6kruHiciGHusJBFtHq/0lGsVQrIkVKx Vs+Q5bHPrTrc39BP4nhucq/W5uYPvY4GZ0l4/kiTzYXuHsUD6PLxWg7LnIO/n3c3lSlB KzC24NnZMacvw4v3RdSwHACvjrgkNcmv20iV5UDJtthCrhXlXDeUvPBy/wI/uaQY5Myr Fj4XU1hKgrAdVXErVpA6JOy3C6/9CQ3fq6j9YIsz05c8j8dsAHaTpXcFZ0hz1OewKFnK d0jVNeV14g5MU/ikf+wVyBTs3B1gYm/hVESwEg8WaBMJA3gG9+ik+tj3zWGxN+hXCych C9Vw== X-Gm-Message-State: AOJu0YwCxXm5bw6gZ6H4cBUECZaLbHiNVlYXhZ2L/q5DsYmywOgrV4tA 8TfPaFMVNzM1W19Aa13ryj4vuzoM8bkaUPhxy5aFQPXunDtvRpRaR4zltL/7dFgnNkvRqyT3474 50H/EvB0B2og= X-Received: by 2002:a05:600c:3410:b0:40c:24a2:6b05 with SMTP id y16-20020a05600c341000b0040c24a26b05mr8037746wmp.206.1702921639910; Mon, 18 Dec 2023 09:47:19 -0800 (PST) X-Google-Smtp-Source: AGHT+IFGz34bu2APKQrNggPPHYfjts7sMyP4aUwKDuYTu+BK+6lzKcu2e5XHatto090CHhq9pkcRKQ== X-Received: by 2002:a05:600c:3410:b0:40c:24a2:6b05 with SMTP id y16-20020a05600c341000b0040c24a26b05mr8037735wmp.206.1702921639453; Mon, 18 Dec 2023 09:47:19 -0800 (PST) Received: from ?IPV6:2003:cb:c72b:b500:b53e:6e32:1408:27ac? (p200300cbc72bb500b53e6e32140827ac.dip0.t-ipconnect.de. [2003:cb:c72b:b500:b53e:6e32:1408:27ac]) by smtp.gmail.com with ESMTPSA id v6-20020a05600c444600b0040c46ba7b66sm33764336wmn.48.2023.12.18.09.47.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 Dec 2023 09:47:19 -0800 (PST) Message-ID: <0bef5423-6eea-446b-8854-980e9c23a948@redhat.com> Date: Mon, 18 Dec 2023 18:47:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 02/16] mm: Batch-copy PTE ranges during fork() To: Ryan Roberts , Catalin Marinas , Will Deacon , Ard Biesheuvel , Marc Zyngier , Oliver Upton , James Morse , Suzuki K Poulose , Zenghui Yu , Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Andrew Morton , Anshuman Khandual , Matthew Wilcox , Yu Zhao , Mark Rutland , Kefeng Wang , John Hubbard , Zi Yan , Barry Song <21cnbao@gmail.com>, Alistair Popple , Yang Shi Cc: linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20231218105100.172635-1-ryan.roberts@arm.com> <20231218105100.172635-3-ryan.roberts@arm.com> From: David Hildenbrand Autocrypt: addr=david@redhat.com; keydata= xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZgEEwEIAEICGwMGCwkIBwMCBhUIAgkKCwQW AgMBAh4BAheAAhkBFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl8Ox4kFCRKpKXgACgkQTd4Q 9wD/g1oHcA//a6Tj7SBNjFNM1iNhWUo1lxAja0lpSodSnB2g4FCZ4R61SBR4l/psBL73xktp rDHrx4aSpwkRP6Epu6mLvhlfjmkRG4OynJ5HG1gfv7RJJfnUdUM1z5kdS8JBrOhMJS2c/gPf wv1TGRq2XdMPnfY2o0CxRqpcLkx4vBODvJGl2mQyJF/gPepdDfcT8/PY9BJ7FL6Hrq1gnAo4 3Iv9qV0JiT2wmZciNyYQhmA1V6dyTRiQ4YAc31zOo2IM+xisPzeSHgw3ONY/XhYvfZ9r7W1l pNQdc2G+o4Di9NPFHQQhDw3YTRR1opJaTlRDzxYxzU6ZnUUBghxt9cwUWTpfCktkMZiPSDGd KgQBjnweV2jw9UOTxjb4LXqDjmSNkjDdQUOU69jGMUXgihvo4zhYcMX8F5gWdRtMR7DzW/YE BgVcyxNkMIXoY1aYj6npHYiNQesQlqjU6azjbH70/SXKM5tNRplgW8TNprMDuntdvV9wNkFs 9TyM02V5aWxFfI42+aivc4KEw69SE9KXwC7FSf5wXzuTot97N9Phj/Z3+jx443jo2NR34XgF 89cct7wJMjOF7bBefo0fPPZQuIma0Zym71cP61OP/i11ahNye6HGKfxGCOcs5wW9kRQEk8P9 M/k2wt3mt/fCQnuP/mWutNPt95w9wSsUyATLmtNrwccz63XOwU0EVcufkQEQAOfX3n0g0fZz Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A 2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75 7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx 5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa N7eop7uh+6bezi+rugUI+w6DABEBAAHCwXwEGAEIACYCGwwWIQQb2cqtc1xMOkYN/MpN3hD3 AP+DWgUCXw7HsgUJEqkpoQAKCRBN3hD3AP+DWrrpD/4qS3dyVRxDcDHIlmguXjC1Q5tZTwNB boaBTPHSy/Nksu0eY7x6HfQJ3xajVH32Ms6t1trDQmPx2iP5+7iDsb7OKAb5eOS8h+BEBDeq 3ecsQDv0fFJOA9ag5O3LLNk+3x3q7e0uo06XMaY7UHS341ozXUUI7wC7iKfoUTv03iO9El5f XpNMx/YrIMduZ2+nd9Di7o5+KIwlb2mAB9sTNHdMrXesX8eBL6T9b+MZJk+mZuPxKNVfEQMQ a5SxUEADIPQTPNvBewdeI80yeOCrN+Zzwy/Mrx9EPeu59Y5vSJOx/z6OUImD/GhX7Xvkt3kq Er5KTrJz3++B6SH9pum9PuoE/k+nntJkNMmQpR4MCBaV/J9gIOPGodDKnjdng+mXliF3Ptu6 3oxc2RCyGzTlxyMwuc2U5Q7KtUNTdDe8T0uE+9b8BLMVQDDfJjqY0VVqSUwImzTDLX9S4g/8 kC4HRcclk8hpyhY2jKGluZO0awwTIMgVEzmTyBphDg/Gx7dZU1Xf8HFuE+UZ5UDHDTnwgv7E th6RC9+WrhDNspZ9fJjKWRbveQgUFCpe1sa77LAw+XFrKmBHXp9ZVIe90RMe2tRL06BGiRZr jPrnvUsUUsjRoRNJjKKA/REq+sAnhkNPPZ/NNMjaZ5b8Tovi8C0tmxiCHaQYqj7G2rgnT0kt WNyWQQ== Organization: Red Hat In-Reply-To: <20231218105100.172635-3-ryan.roberts@arm.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 45E5680002 X-Rspam-User: X-Stat-Signature: 9n9nwejru7op14aqzpf8qkkeogfccfdu X-Rspamd-Server: rspam03 X-HE-Tag: 1702921643-359527 X-HE-Meta: U2FsdGVkX18g5Rph9s3lEGiRgwMCkjp8glm7/k6m3+gxq5DIGM5h0mQwsYYdiTzYavP8uwv3nwd126IPu0GIU9T4EhQqdYM914u1pp5fZS6vliySAsoUN3pwhrSPYTC2rvfn9+ulbFWUyX/p5Se6ia0SrnRpU8pSPidqtrHmSSNCVvUOUL+uXTPFV/LXGlLUsNtGVa6NRYaP5UMUy7hXcLoVbTr2sDiLJXodweGHb8bnivDCuZa3PwONEuFQbwr9MM0buKzWeuojXSpPD8AhGwUU4iUKxRKGFPT3KWsjv8IYA4s2rjUMfFdRtkcTS/mbIvzY8r3utkKOOPhgohBrJ1vBkCMPB8DFv60eWs8KGD8ZqH94rfQooznEP03WH8Ag2HWpig5naTKpOuRI3HZeLrOrCWtMX5Ypb+iPnoe29DkftyuZMAbcCU02zFR271FPBj4aRrslhOoUmeOeYe6lZwJvQTfktBybv+QjufjXf3Zfn1CiaMjqU3hnm4h+krsqMk/NI+6J/5og7hsXDmSUWwc332tBXmoi8WkJ0Zf7ACIpaMHoOf4n9slW8TVircIr9QPfijw8K/PkOn0dHxL3OcaOWn3hrwT1YdKiNVMXuJJknFapGpv8HJPkTduMZ4L58idt+dRofur2zFD4nIg92ggBfrlpx7v5cQVGC2uS4DwWIXVDawoOabJsV29Yv/oR2JbZhi01azB+auk4qytMS1VPcuZW5TMnbFKfi/BtGsNATqyo5IoKIcgLyF6yaRaubFKHaBz7HohAZQzebGb4mDT2PoZirMYl8btn4UVVbdgf2BJ5DnsJKyp5LN7QGxHJXKANeJDdzkWcOLOKTlZRVqAqFDkU9o7DU6d/oQ6mD7hHwPD2c579XB5aSxFrofuVr9QbmhlMM+AUV3/Z2ZvdSaCKNx17312AQxiAOJfVkMZPWsW+5U1YU2hu6LVCuSlMQC0ajG/1iKQ6f15f/B3 6Ymc+GVQ eMiG49G/Jm264F/ch9SiE2+xNRllkHYoZ/98H3TWsXmdg7Nuu0ys7r6m1XhgIWaoir4vG7kea7CDw1lFbl4/+oRSKc1D/Vpnd+TKEI2NYIKstY3ZLHabOP8410RQMcLUMCAGVD9NSjGTvKegV7gI0XCmUDD5sWO9OQq86VZ3RYd0fS3FdACxD8QL/2eFkFYKb4ZdwRKj91VRIraP3bCYdcKSz5m2EYUZWIpRd9v3q+DkqQ6mG63zB3mUQbHcJL0jI6wws9unsth5Dt685w5CEjOW3Owc37JPE+s8BwTo9NDGd9YUwm81KT48AwUndLuEtADAisYPdJIZSIs2lhiDLCRXcqkU8MzDCLbPd8NfVK+slWtnPBZkJgGjntITO4s748toZTr+0yXBEUDQkkRQVR+tvnjPkZq/xo4UnU3s9grElN3IsKO+MOZQm5KumxMaEh8tppfgnUg8jpLod39kL1umqsxOH75Vj4HmR1wCYtwHq4cC0Y0xeXQuDDS0r/KrqOHcsOUT4aOYv8ZQuik0eOFQHp8MtpnuES6LAQAc4qJ5/3JonG0Kp7tJx6y0NrRMs08Pm X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 18.12.23 11:50, Ryan Roberts wrote: > Convert copy_pte_range() to copy a batch of ptes in one go. A given > batch is determined by the architecture with the new helper, > pte_batch_remaining(), and maps a physically contiguous block of memory, > all belonging to the same folio. A pte batch is then write-protected in > one go in the parent using the new helper, ptep_set_wrprotects() and is > set in one go in the child using the new helper, set_ptes_full(). > > The primary motivation for this change is to reduce the number of tlb > maintenance operations that the arm64 backend has to perform during > fork, as it is about to add transparent support for the "contiguous bit" > in its ptes. By write-protecting the parent using the new > ptep_set_wrprotects() (note the 's' at the end) function, the backend > can avoid having to unfold contig ranges of PTEs, which is expensive, > when all ptes in the range are being write-protected. Similarly, by > using set_ptes_full() rather than set_pte_at() to set up ptes in the > child, the backend does not need to fold a contiguous range once they > are all populated - they can be initially populated as a contiguous > range in the first place. > > This code is very performance sensitive, and a significant amount of > effort has been put into not regressing performance for the order-0 > folio case. By default, pte_batch_remaining() is compile constant 1, > which enables the compiler to simplify the extra loops that are added > for batching and produce code that is equivalent (and equally > performant) as the previous implementation. > > This change addresses the core-mm refactoring only and a separate change > will implement pte_batch_remaining(), ptep_set_wrprotects() and > set_ptes_full() in the arm64 backend to realize the performance > improvement as part of the work to enable contpte mappings. > > To ensure the arm64 is performant once implemented, this change is very > careful to only call ptep_get() once per pte batch. > > The following microbenchmark results demonstate that there is no > significant performance change after this patch. Fork is called in a > tight loop in a process with 1G of populated memory and the time for the > function to execute is measured. 100 iterations per run, 8 runs > performed on both Apple M2 (VM) and Ampere Altra (bare metal). Tests > performed for case where 1G memory is comprised of order-0 folios and > case where comprised of pte-mapped order-9 folios. Negative is faster, > positive is slower, compared to baseline upon which the series is based: > > | Apple M2 VM | order-0 (pte-map) | order-9 (pte-map) | > | fork |-------------------|-------------------| > | microbench | mean | stdev | mean | stdev | > |---------------|---------|---------|---------|---------| > | baseline | 0.0% | 1.1% | 0.0% | 1.2% | > | after-change | -1.0% | 2.0% | -0.1% | 1.1% | > > | Ampere Altra | order-0 (pte-map) | order-9 (pte-map) | > | fork |-------------------|-------------------| > | microbench | mean | stdev | mean | stdev | > |---------------|---------|---------|---------|---------| > | baseline | 0.0% | 1.0% | 0.0% | 0.1% | > | after-change | -0.1% | 1.2% | -0.1% | 0.1% | > > Tested-by: John Hubbard > Reviewed-by: Alistair Popple > Signed-off-by: Ryan Roberts > --- > include/linux/pgtable.h | 80 +++++++++++++++++++++++++++++++++++ > mm/memory.c | 92 ++++++++++++++++++++++++++--------------- > 2 files changed, 139 insertions(+), 33 deletions(-) > > diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h > index af7639c3b0a3..db93fb81465a 100644 > --- a/include/linux/pgtable.h > +++ b/include/linux/pgtable.h > @@ -205,6 +205,27 @@ static inline int pmd_young(pmd_t pmd) > #define arch_flush_lazy_mmu_mode() do {} while (0) > #endif > > +#ifndef pte_batch_remaining > +/** > + * pte_batch_remaining - Number of pages from addr to next batch boundary. > + * @pte: Page table entry for the first page. > + * @addr: Address of the first page. > + * @end: Batch ceiling (e.g. end of vma). > + * > + * Some architectures (arm64) can efficiently modify a contiguous batch of ptes. > + * In such cases, this function returns the remaining number of pages to the end > + * of the current batch, as defined by addr. This can be useful when iterating > + * over ptes. > + * > + * May be overridden by the architecture, else batch size is always 1. > + */ > +static inline unsigned int pte_batch_remaining(pte_t pte, unsigned long addr, > + unsigned long end) > +{ > + return 1; > +} > +#endif It's a shame we now lose the optimization for all other archtiectures. Was there no way to have some basic batching mechanism that doesn't require arch specifics? I'd have thought that something very basic would have worked like: * Check if PTE is the same when setting the PFN to 0. * Check that PFN is consecutive * Check that all PFNs belong to the same folio -- Cheers, David / dhildenb