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 BEAD0C6FD1C for ; Thu, 9 Mar 2023 11:09:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5A2C06B0071; Thu, 9 Mar 2023 06:09:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5520B6B0072; Thu, 9 Mar 2023 06:09:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 440986B0075; Thu, 9 Mar 2023 06:09:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 339B46B0071 for ; Thu, 9 Mar 2023 06:09:09 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id F192714104E for ; Thu, 9 Mar 2023 11:09:08 +0000 (UTC) X-FDA: 80549087976.05.8EFF412 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf01.hostedemail.com (Postfix) with ESMTP id 285FD40018 for ; Thu, 9 Mar 2023 11:09:06 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf01.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=1678360147; 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=uiBI0/EFW0W7yVwmm+mLPVt2R/jTCZwHY6H1yw6Gm4U=; b=PhOn2QZqix4qskQ7dmAXC3fcTgZ33SzgGC7ZGYYEwh4rMK530FDkr5frGpHQYddm3AmvW8 GoyFuGeNos/nw2jXpi94cvIIoiYja72MXsGxahYeVs1kFMdK2nl/vfpDwb7sYVd9solYZK JBAaEUtIdGuP5d290ngn/GYZ3gmoGrQ= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf01.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=1678360147; a=rsa-sha256; cv=none; b=dqrcjOvhacMi25k5FWgKnhRWVIpKKVgZjzjb+0oHUMZjbFe8XYPzulAoj7LfqjubktRCBa S3dVYPHyzAJhn1MQz0sHWGsJd62HaPySMPXyttU1cOWVUxBxBKqmESiJwDtCk/TCU+l9bv YdLOxMc7YVxQ1BBsHJs71Qp5j5zDgBE= 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 B4F04C14; Thu, 9 Mar 2023 03:09:49 -0800 (PST) Received: from [10.1.27.175] (C02CF1NRLVDN.cambridge.arm.com [10.1.27.175]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A51BF3F67D; Thu, 9 Mar 2023 03:09:05 -0800 (PST) Message-ID: <5e2f8747-cff8-08ac-7280-f8978cbf56a8@arm.com> Date: Thu, 9 Mar 2023 11:09:04 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH v3 00/34] New page table range API Content-Language: en-US To: "Matthew Wilcox (Oracle)" , linux-mm@kvack.org, linux-arch@vger.kernel.org Cc: linux-kernel@vger.kernel.org References: <20230228213738.272178-1-willy@infradead.org> From: Ryan Roberts In-Reply-To: <20230228213738.272178-1-willy@infradead.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 285FD40018 X-Stat-Signature: r5gcstr3eg6naemsrtfjjqdrbb55cuuf X-HE-Tag: 1678360146-707402 X-HE-Meta: U2FsdGVkX18Y4y8lGEBTiTZz7UcAZCfoVbHRS5C8L4nYjMlfg+jcnG+C3v7KSUVPd9XAYBLFa/zn0TeXJY3VjzhLej0T2luRynwnEUlpoDAah/SJeary3aBp/DeYovvVSoLEXcjV1mLXFgRTJKpwFiTSGR69eZ6OTTRjIPusMRQic1WckGQaUtKWV1sk0IDhI6Msz82fyZjnYIwl8KOA28gLAeFjzBwCwx0yZo7tBzJLU2HTADfQxRhppb4xBeDjQtMas4x6KGNzSNVQ1qoEt70s/MooODqR5FhZ2/pxo8w6kZ3pgwaV5+xG3hTCfEbDSqBbpG1hUN3pRsBHg5bJ1hXhT3pAsIdR09CWcxatTv1thnO4BB70B8cJkfDy99Fb0IZa8GFCoEaZUW1pY2vHppoECmn5fTLAiK1mL4yHGtdcR+xOfjWdU8a5DgfzHrcN9cd5NtHmSqxEw3/ZvCe5ax8cWZLkqy8VcjzTmf8jSL002PTQH1/5ArvHKHDg2pxy7LASX9fCsIcBG7Gab3mOMYKW+DGjDaMB5w5dPbDkz3arSPxQLMKW5iNUM6MIfzex7KgF+GAVbX/QPqdteltRFc/MweHr6mhpyQ7q1Vbn/q5+1ioloq9u6mRAFDA5Bh08AyzYDMmWJk8JdrsjJTt3JFBTX7mANbPjFb1RjYXK7cuGe0G1B5z2kv8yGVzMEcWro/mlI0lDZLlv+yCE6qsNCSJdGKe/UJJ0cjGxt87b5X6CyL1PtwkZHadnlco+DXWaepIilinSKJhlL/hX8Nsfus4ukEtXfpMMqvVg0t6kdfKG/pZMm05TEU85eB4nhmfwvCWgCqHqYb+kDMDLWbyfy3cYjL5A3U2oDaHzBOIt1YKQv1hKMX55B9tBUAR6Rzwuegqz2TROtZRE9GKKBGPgAgD12jUjLdIqpxmiBNtuUG7eht5sOJul5PoSouFFi7bQjTrr4t+rz4WxWD5bj8/ 05ZxgHE5 lf+v/8Q6LuZBYphWoJevFdiQIYqZYadrz5QdyBqdwkCfwXTfLwULR6Yz0gDBy2aZegLxOeHnQR9L2CL4dGauCE1nueM6/eZMvigNutBaRWh767XbB3pdmpGHePBlz54LEya09yBO7pygEwBghJpOuJSNfkxxpj1CJUDvO34lJjsUVOgie5jrfxyCHlnNQ5xKm8bMUX/K9c8R1DmOjXhE6EJoSSmDMD1wZcGaHxTuTob97qT190E7azo9DWyyH1P/TRfDe2QCijEWpmEg= 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 28/02/2023 21:37, Matthew Wilcox (Oracle) wrote: > This patchset changes the API used by the MM to set up page table entries. > The four APIs are: > set_ptes(mm, addr, ptep, pte, nr) > update_mmu_cache_range(vma, addr, ptep, nr) > flush_dcache_folio(folio) > flush_icache_pages(vma, page, nr) > > flush_dcache_folio() isn't technically new, but no architecture > implemented it, so I've done that for you. The old APIs remain around > but are mostly implemented by calling the new interfaces. > > The new APIs are based around setting up N page table entries at once. > The N entries belong to the same PMD, the same folio and the same VMA, > so ptep++ is a legitimate operation, and locking is taken care of for > you. Some architectures can do a better job of it than just a loop, > but I have hesitated to make too deep a change to architectures I don't > understand well. > > One thing I have changed in every architecture is that PG_arch_1 is now a > per-folio bit instead of a per-page bit. This was something that would > have to happen eventually, and it makes sense to do it now rather than > iterate over every page involved in a cache flush and figure out if it > needs to happen. > > The point of all this is better performance, and Fengwei Yin has > measured improvement on x86. I suspect you'll see improvement on > your architecture too. Try the new will-it-scale test mentioned here: > https://lore.kernel.org/linux-mm/20230206140639.538867-5-fengwei.yin@intel.com/ > You'll need to run it on an XFS filesystem and have > CONFIG_TRANSPARENT_HUGEPAGE set. > > For testing, I've only run the code on x86. If an x86->foo compiler > exists in Debian, I've built defconfig. I'm relying on the buildbots > to tell me what I missed, and people who actually have the hardware to > tell me if it actually works. > > I'd like to get this into the MM tree soon after the current merge window > closes, so quick feedback would be appreciated. I've boot-tested the series (with the Yin's typo fix for patch 32) on arm64 FVP and Ampere Altra. On the Altra, I also ran page_fault4 from will-it-scale, and see ~35% improvement from this series. So: Tested-by: Ryan Roberts Thanks, Ryan