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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9062FC35274 for ; Mon, 18 Dec 2023 17:47:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=6paEW2g+WcYxiik/p4jl8Fj2eM4nQPk0ir9xiGGM2hE=; b=sLFuc2gmiuhGr1 OHiJ6c5J1kwM6V3CMTN0DzPHjp74tBkD835pfd3zxdnU4KbT4jYTqDkEnvTnxVA+BbFmqhEvkm6Ig N30m4Asp9HWEpf8NxHoFGnYs4Dd3rD4WdWRt2lyDS5Q5o0PCHEEjck05oGsYT68JHECkvd98Q8qXs zX2XZ7myS/BUMTn/t2O59moDdOpjJQRwGqqZgmkdWKHuKzTyxkCxKYyh9Dr22BMBzI0d+NtkcjKo0 jv6k8VSt6L2+S+lhSvF01W+ywqbUab6NRw7FzoMWDAc4+1oQKb8mwkEOE3y+HfpkjtLQjgiEDLrXl yOpfgLBeTBW24+korICg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rFHiC-00Bgab-2i; Mon, 18 Dec 2023 17:47:28 +0000 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rFHi9-00BgZT-1J for linux-arm-kernel@lists.infradead.org; Mon, 18 Dec 2023 17:47:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1702921644; 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=Pefn1pAtq89b0rKmzFKLiLd4W28+Il0YYI1ZW/FuSr61g3ZcAZBFiT51H6x8ocfnupqRp1 Ov/qMAUPTFYY5A5BSYCN/e2Lhz8EFS5JxYE8edi0Ur+qSCTMJ24oqGbJpJ/Cua66A6NsbT XAvBeAtJgLAlJDnxUskd9WDprNZ1RTo= 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-mingDdLkO0GSelAHQoYQcA-1; Mon, 18 Dec 2023 12:47:21 -0500 X-MC-Unique: mingDdLkO0GSelAHQoYQcA-1 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-40c3cea4c19so30488235e9.1 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=oyDnsAHS7K/mgfwBMPbGbfhCjnpeBqRprJ4jpg/FSwHpcqdb2I+EXHxlqKzscbhCcB 4NEa5QdTOrfX2ryoPyz5r8eDewLPrLvG1yl6mKU1cGxJ31fDui0y0a+2E8otOsfOo288 QkdFIPlvBPHhTJIj//xan3E8IL+Svve+lIuwJJF7+IzZ2O+cHberpeuLC89qkGjjDA6f qnl9ocRqnBowg4s4CuHvMzdGijb+kJudcv+Cpajd8kdlHBVfGirepbWPkHXBamvaURQr RG3LYfkG8PtFHIF6ptCoiOEnUnyzbL0HjBU0PFwJ7ibCeOBrVavj+dWkLdBcrfSZKvtN YznQ== X-Gm-Message-State: AOJu0YxEQlJlSHxQAJ9WfIffbvGVkftKlxrwNS6PDfFnP4H771jp2FiC bWmiERqqSk2JrDJH0yn3tOWDsz8Q4QP89Diea6gPd9/HZSWNdAP3UTwdVjWMnGpgD6LkbXb45aM EsQHLa7cmzBus5fgpHbmygcW0q1lY9ITgZus= X-Received: by 2002:a05:600c:3410:b0:40c:24a2:6b05 with SMTP id y16-20020a05600c341000b0040c24a26b05mr8037764wmp.206.1702921639915; 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231218_094725_538627_51B21B4C X-CRM114-Status: GOOD ( 37.85 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel