From patchwork Thu Feb 15 12:17:52 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ryan Roberts X-Patchwork-Id: 13558309 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 25668C4829E for ; Thu, 15 Feb 2024 12:18:32 +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-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-Id:Date:Subject:Cc :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=WVWT/MY4seaoxa8gtFCWDwjEyRsWqSUHiRUJFyH37D8=; b=sw+UtwbjpQWliq aCs1J7WQZJhV5gnhe2Y1BaedVMayY5yupJ/KqffiuQybPRTkBG4GMlB4eki2rf+MW8UxSnsMxJVx8 t9F2F8yFw+echpKzjkZc1QueF+fjwPTWNHhJcCgXOweBec2v801qNat5R4iE9M55+47YWnVU71Uwk r+zFhE+SU8LpoSIG35TRGc7Kqe82lok3HVEKlOGKRd8dwh0s8Q/wPup0AfalaXXLwIAUc+0/O6r4H N48r1kAoWcJXHhinIqGLwWvmaBzE/R838BLx5b53OJvUiqc1MFBjLaChWdn4FIHjYPjZBlHGmMsil MdjNzri3aOvj92T4GY/Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1raagt-0000000GCCF-3vKT; Thu, 15 Feb 2024 12:18:11 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1raagr-0000000GCAj-31qy for linux-arm-kernel@lists.infradead.org; Thu, 15 Feb 2024 12:18:11 +0000 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 C309F1FB; Thu, 15 Feb 2024 04:18:46 -0800 (PST) Received: from e125769.cambridge.arm.com (e125769.cambridge.arm.com [10.1.196.26]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 256853F766; Thu, 15 Feb 2024 04:18:04 -0800 (PST) From: Ryan Roberts To: David Hildenbrand , Mark Rutland , Catalin Marinas , Will Deacon , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , Andrew Morton , Muchun Song Cc: Ryan Roberts , linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [RFC PATCH v1 0/4] Reduce cost of ptep_get_lockless on arm64 Date: Thu, 15 Feb 2024 12:17:52 +0000 Message-Id: <20240215121756.2734131-1-ryan.roberts@arm.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240215_041809_838359_9E4CC992 X-CRM114-Status: GOOD ( 15.13 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org This is an RFC for a series that aims to reduce the cost and complexity of ptep_get_lockless() for arm64 when supporting transparent contpte mappings [1]. The approach came from discussion with Mark and David [2]. It introduces a new helper, ptep_get_lockless_norecency(), which allows the access and dirty bits in the returned pte to be incorrect. This relaxation permits arm64's implementation to just read the single target pte, and avoids having to iterate over the full contpte block to gather the access and dirty bits, for the contpte case. It turns out that none of the call sites using ptep_get_lockless() require accurate access and dirty bit information, so we can also convert those sites. Although a couple of places need care (see patches 2 and 3). Arguably patch 3 is a bit fragile, given the wide accessibility of vmf->orig_pte. So it might make sense to drop this patch and stick to using ptep_get_lockless() in the page fault path. I'm keen to hear opinions. I've chosen the name "recency" because it's shortish and somewhat descriptive, and is alredy used in a couple of places to mean similar things (see mglru and damon). I'm open to other names if anyone has better ideas. If concensus is that this approach is generally acceptable, I intend to create a series in future to do a similar thing with ptep_get() -> ptep_get_norecency(). --- This series applies on top of [1]. [1] https://lore.kernel.org/linux-mm/20240215103205.2607016-1-ryan.roberts@arm.com/ [2] https://lore.kernel.org/linux-mm/a91cfe1c-289e-4828-8cfc-be34eb69a71b@redhat.com/ Thanks, Ryan Ryan Roberts (4): mm: Introduce ptep_get_lockless_norecency() mm/gup: Use ptep_get_lockless_norecency() mm/memory: Use ptep_get_lockless_norecency() for orig_pte arm64/mm: Override ptep_get_lockless_norecency() arch/arm64/include/asm/pgtable.h | 6 ++++ include/linux/pgtable.h | 55 ++++++++++++++++++++++++++++-- kernel/events/core.c | 2 +- mm/gup.c | 7 ++-- mm/hugetlb.c | 2 +- mm/khugepaged.c | 2 +- mm/memory.c | 57 ++++++++++++++++++++------------ mm/swap_state.c | 2 +- mm/swapfile.c | 2 +- 9 files changed, 102 insertions(+), 33 deletions(-) -- 2.25.1