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 158FBEB64D9 for ; Tue, 27 Jun 2023 09:59:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 752FA8D0002; Tue, 27 Jun 2023 05:59:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 703C48D0001; Tue, 27 Jun 2023 05:59:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5F3888D0002; Tue, 27 Jun 2023 05:59:29 -0400 (EDT) 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 5243D8D0001 for ; Tue, 27 Jun 2023 05:59:29 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 1263114090E for ; Tue, 27 Jun 2023 09:59:29 +0000 (UTC) X-FDA: 80948080458.21.13D5C0C Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf21.hostedemail.com (Postfix) with ESMTP id 41B381C0016 for ; Tue, 27 Jun 2023 09:59:27 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf21.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687859967; 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; bh=z6HLMrIrFkeh8DtYwoQzyKMzL0/zvamsZmv0oqQlQkQ=; b=DrHFfQ0yeT7AoCMwKsQ6gY/Msiv5gVM6Qnpi0W8KiscXNq4xHGnODYKJaF8AWI53oMdhjq 5J0ddnoui6czl8iLbX47jKysPLKm/5sK+Gyll0F+iVx8NXDhA5HGt1r4P01jGUhKfCllgT sJW+fUedA1vmXBVhg4BpylNYyUMhI/w= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf21.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687859967; a=rsa-sha256; cv=none; b=MJVgxZpD92dr84uV3nsJKK5PfHCOKdFj192alCQ/mY1CrA5nKJwpHuI8NrfbwxowDMuEDS T6xwSycYB9NJCuxfDD5S+m4nNJVPo5PQouwnYizB11lFMheStsM4QbwGhnXxfOcmIuxkIz /4kZg86WlVwKtZwPbg+OC6Nn7wh0rbg= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 756CC2F4; Tue, 27 Jun 2023 03:00:10 -0700 (PDT) Received: from [10.1.30.74] (C02Z41KALVDN.cambridge.arm.com [10.1.30.74]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A99B83F64C; Tue, 27 Jun 2023 02:59:23 -0700 (PDT) Message-ID: <1fb0c4cb-a709-de20-d643-32ed43550059@arm.com> Date: Tue, 27 Jun 2023 10:59:22 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH v1 00/10] variable-order, large folios for anonymous memory To: Yu Zhao Cc: Andrew Morton , "Matthew Wilcox (Oracle)" , "Kirill A. Shutemov" , Yin Fengwei , David Hildenbrand , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Christian Borntraeger , Sven Schnelle , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-alpha@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-s390@vger.kernel.org References: <20230626171430.3167004-1-ryan.roberts@arm.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Stat-Signature: w8xztuhpanqcqou1cz9s7srmqzugq31o X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 41B381C0016 X-HE-Tag: 1687859967-550445 X-HE-Meta: U2FsdGVkX1/4ZUGlUhCFq3xeEe9pCvazb+5IkhXS2y+r9j4nCNWIYfwd2YXU0iEuESfNGqhSOdzI6R0uV9AOgtt2K8utwOfbtbFp1k58CR+jAk10wU/W0HqGfuD6yUTt6TGPXhC4UN2So0vf8fX5MtLcmvzeisAXPd2TmU3sXJsuYZv7EIgggR3lPwueJJLoz3FCJIMzO1Ldmf13r/OB2bM7WBSLs4vig5kxbPR3wWzTeNktKJ1ZFKACJRkXhdDVt1pg7041Of5CX+r6xvDGRWbUxBR3oT/xJdllKmpfWSKSB7+nTX0zF3qc6Vyl6j/4XpcQ9NlPM+vnLsLAM/cyzJY16vBRBXzvIpAGAHrey1ZRR+H66FXTjWpYw7T2ZNxmWSI4YO26NZQ1OuYYlzxXfU7liLmw8aVpLWgK9PdmmQkZSa97L+vYfsuasyK1B5/uWI77NKedvFAUvLYB4ACpmHt5xozPbR8jmP3QFoKa4dFX7WL70p27yEqaA4tV2mrWeu/GTDaOjnU5L2UCFJ0sfTvFDvG7pNSU0lr1eUFpiyx/erF1XvXuh88rab5N0ybBYUR+jcZJZWJcZ3h6Wkg55Y3HV285vizQUPzPKF7r5KrXincyErVRwOwPqr1hxPy1Th9aayouZVRwEYy7jr/DDODwIcyCQhT0upV4xLKgN1M3+Jgc2xYJjci1P54I39ZL8FrxJa3kTMJ8ICVDcAB/TPzNlVqqM+JvoV9kz3ZypBjMTbcktOJQ/Gd54CQiYEOoEbeu/ebim3wa/tFVPo8vbROF05hxzJpnZksZL1fB+9lUjL2NI6WfM1fUuygOJMPnvke2ek2862uS9DJwj6u0+5SXsvTi22NBqukmqX+z/Ruzy1kbf0dLWyUGbONX6kf1Zfx0aAQvxJByHZa4NroIdSzPYt/1TjA6QO8C5uZQ4SjEnmegQSb3/AsRRM19hYWuxkK5du+RIUpFBsgATWI DOmFGVDn ZyIXnf4zjMuqlGrdyunW/gwGhipi+QqBiTaJtJjZaUA9uT7V53WhKV23oz0bNnZaJ1NLBobDUjbDe3mOtjwEKJfRgrqt8hylk2GJ/sh2/FM3RyQmZ6rNdFMtEKFGeUtYuCe5PTfawWCSZhyUi8KGBIPW0jAi82Ytu4NExttWtEb9FaGvqfASlnYRh9AumtGlXZN3d 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: On 27/06/2023 08:49, Yu Zhao wrote: > On Mon, Jun 26, 2023 at 9:30 PM Yu Zhao wrote: >> >> On Mon, Jun 26, 2023 at 11:14 AM Ryan Roberts wrote: >>> >>> Hi All, >>> >>> Following on from the previous RFCv2 [1], this series implements variable order, >>> large folios for anonymous memory. The objective of this is to improve >>> performance by allocating larger chunks of memory during anonymous page faults: >>> >>> - Since SW (the kernel) is dealing with larger chunks of memory than base >>> pages, there are efficiency savings to be had; fewer page faults, batched PTE >>> and RMAP manipulation, fewer items on lists, etc. In short, we reduce kernel >>> overhead. This should benefit all architectures. >>> - Since we are now mapping physically contiguous chunks of memory, we can take >>> advantage of HW TLB compression techniques. A reduction in TLB pressure >>> speeds up kernel and user space. arm64 systems have 2 mechanisms to coalesce >>> TLB entries; "the contiguous bit" (architectural) and HPA (uarch). >>> >>> This patch set deals with the SW side of things only and based on feedback from >>> the RFC, aims to be the most minimal initial change, upon which future >>> incremental changes can be added. For this reason, the new behaviour is hidden >>> behind a new Kconfig switch, CONFIG_LARGE_ANON_FOLIO, which is disabled by >>> default. Although the code has been refactored to parameterize the desired order >>> of the allocation, when the feature is disabled (by forcing the order to be >>> always 0) my performance tests measure no regression. So I'm hoping this will be >>> a suitable mechanism to allow incremental submissions to the kernel without >>> affecting the rest of the world. >>> >>> The patches are based on top of v6.4 plus Matthew Wilcox's set_ptes() series >>> [2], which is a hard dependency. I'm not sure of Matthew's exact plans for >>> getting that series into the kernel, but I'm hoping we can start the review >>> process on this patch set independently. I have a branch at [3]. >>> >>> I've posted a separate series concerning the HW part (contpte mapping) for arm64 >>> at [4]. >>> >>> >>> Performance >>> ----------- >>> >>> Below results show 2 benchmarks; kernel compilation and speedometer 2.0 (a >>> javascript benchmark running in Chromium). Both cases are running on Ampere >>> Altra with 1 NUMA node enabled, Ubuntu 22.04 and XFS filesystem. Each benchmark >>> is repeated 15 times over 5 reboots and averaged. >>> >>> All improvements are relative to baseline-4k. 'anonfolio-basic' is this series. >>> 'anonfolio' is the full patch set similar to the RFC with the additional changes >>> to the extra 3 fault paths. The rest of the configs are described at [4]. >>> >>> Kernel Compilation (smaller is better): >>> >>> | kernel | real-time | kern-time | user-time | >>> |:----------------|------------:|------------:|------------:| >>> | baseline-4k | 0.0% | 0.0% | 0.0% | >>> | anonfolio-basic | -5.3% | -42.9% | -0.6% | >>> | anonfolio | -5.4% | -46.0% | -0.3% | >>> | contpte | -6.8% | -45.7% | -2.1% | >>> | exefolio | -8.4% | -46.4% | -3.7% | >>> | baseline-16k | -8.7% | -49.2% | -3.7% | >>> | baseline-64k | -10.5% | -66.0% | -3.5% | >>> >>> Speedometer 2.0 (bigger is better): >>> >>> | kernel | runs_per_min | >>> |:----------------|---------------:| >>> | baseline-4k | 0.0% | >>> | anonfolio-basic | 0.7% | >>> | anonfolio | 1.2% | >>> | contpte | 3.1% | >>> | exefolio | 4.2% | >>> | baseline-16k | 5.3% | >> >> Thanks for pushing this forward! >> >>> Changes since RFCv2 >>> ------------------- >>> >>> - Simplified series to bare minimum (on David Hildenbrand's advice) >> >> My impression is that this series still includes many pieces that can >> be split out and discussed separately with followup series. >> >> (I skipped 04/10 and will look at it tomorrow.) > > I went through the series twice. Here what I think a bare minimum > series (easier to review/debug/land) would look like: > 1. a new arch specific function providing a prefered order within (0, > PMD_ORDER). > 2. an extended anon folio alloc API taking that order (02/10, partially). > 3. an updated folio_add_new_anon_rmap() covering the large() && > !pmd_mappable() case (similar to 04/10). > 4. s/folio_test_pmd_mappable/folio_test_large/ in page_remove_rmap() > (06/10, reviewed-by provided). > 5. finally, use the extended anon folio alloc API with the arch > preferred order in do_anonymous_page() (10/10, partially). > > The rest can be split out into separate series and move forward in > parallel with probably a long list of things we need/want to do. Thanks for the fadt review - I really appreciate it! I've responded to many of your comments. I'd appreciate if we can close those points then I will work up a v2. Thanks, Ryan