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 9C1DAC433EF for ; Mon, 31 Jan 2022 08:07:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 00C5F6B0074; Mon, 31 Jan 2022 03:07:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EFF2F6B0075; Mon, 31 Jan 2022 03:07:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DEE4D6B0078; Mon, 31 Jan 2022 03:07:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay032.a.hostedemail.com [64.99.140.32]) by kanga.kvack.org (Postfix) with ESMTP id D26216B0074 for ; Mon, 31 Jan 2022 03:07:32 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 9392922743 for ; Mon, 31 Jan 2022 08:07:32 +0000 (UTC) X-FDA: 79089852744.03.28EF45E Received: from server.lespinasse.org (server.lespinasse.org [63.205.204.226]) by imf01.hostedemail.com (Postfix) with ESMTP id 2509240006 for ; Mon, 31 Jan 2022 08:07:31 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=lespinasse.org; i=@lespinasse.org; q=dns/txt; s=srv-53-ed; t=1643616449; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to : from; bh=DUls+NSqCzLwdMvu9DMfYrIm8aID0KapGH5s3ZOvbmM=; b=HO/JA3FzstU7ddJ40KAF/Lb2XFouhcOhmEQwjCTTi0nYal7+D3kVQjpqaRVJ+9Frc1C9N C4GY0hPtgTCiIAQCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lespinasse.org; i=@lespinasse.org; q=dns/txt; s=srv-53-rsa; t=1643616449; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to : from; bh=DUls+NSqCzLwdMvu9DMfYrIm8aID0KapGH5s3ZOvbmM=; b=aLVrOmahxQg+ZOd/LoQHUx/7vByrwGN7Xd0dgQQNhU1I5GVOkMKA7nwyXIK5UP7XG5MKH RDvCQZtIxBc7eLbNoXfJZzLQIOiTrWV+KMpLiNPvpV/Uu3zd3xLayV5lggbB7m8AjzCH2J8 uLAn8QWVKes4qJdhfJfW3+v0RkWs4zhSLpxoXf/bLQwO08xqJKgYm8L30aAP/42vOrD7AEm vh3D9K+S5i6eVVk+jTE5EDJ57vc+QvmGKFV6bue6mI0pzBINsv57zAY6cUWPhLsGmVXzNfO fHyzKWELMEidcbPxbnLI9yA4e378PpkDyia5zYcDBWtUKkAEMb2jkch9sY8w== Received: by server.lespinasse.org (Postfix, from userid 1000) id D1A82160968; Mon, 31 Jan 2022 00:07:29 -0800 (PST) Date: Mon, 31 Jan 2022 00:07:29 -0800 From: Michel Lespinasse To: Mike Rapoport Cc: Michel Lespinasse , Linux-MM , linux-kernel@vger.kernel.org, Andrew Morton , kernel-team@fb.com, Laurent Dufour , Jerome Glisse , Peter Zijlstra , Michal Hocko , Vlastimil Babka , Davidlohr Bueso , Matthew Wilcox , Liam Howlett , Rik van Riel , Paul McKenney , Song Liu , Suren Baghdasaryan , Minchan Kim , Joel Fernandes , David Rientjes , Axel Rasmussen , Andy Lutomirski Subject: Re: [PATCH v2 33/35] arm64/mm: attempt speculative mm faults first Message-ID: <20220131080729.GA785@lespinasse.org> References: <20220128131006.67712-1-michel@lespinasse.org> <20220128131006.67712-34-michel@lespinasse.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=lespinasse.org header.s=srv-53-ed header.b="HO/JA3Fz"; dkim=pass header.d=lespinasse.org header.s=srv-53-rsa header.b=aLVrOmah; spf=pass (imf01.hostedemail.com: domain of michel@lespinasse.org designates 63.205.204.226 as permitted sender) smtp.mailfrom=michel@lespinasse.org; dmarc=pass (policy=none) header.from=lespinasse.org X-Rspam-User: nil X-Rspamd-Queue-Id: 2509240006 X-Stat-Signature: o4qxfwe7zo1m3s5d8cm1g7tj9syg19z7 X-Rspamd-Server: rspam12 X-HE-Tag: 1643616451-248781 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 Sun, Jan 30, 2022 at 11:13:26AM +0200, Mike Rapoport wrote: > The speculative page fault implementation here (and for PowerPC as well) > looks very similar to x86. Can we factor it our rather than copy 3 (or > more) times? In each arch, the speculative code was written along the lines of the existing non-speculative code, so that behavior would be unchanged when speculation succeeds. Now each arch's existing, non-speculative code paths are quite similar, but they do have small differences as to how they implement various permission checks, protection keys and the like. The same small differences end up being reflected in the new speculative code paths. I agree it would be nice if this code could be unified between archs, but IMO this should start with the existing non-speculative code - I don't think it would make sense to try unifying the new speculative code while trying to follow the behavior of the non-unified old non-speculative code paths...