Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp1272701pxb; Wed, 2 Feb 2022 00:39:13 -0800 (PST) X-Google-Smtp-Source: ABdhPJztqK0Yy1St/HGY8pisiT0nPs4qbu04VyryEa5DdpPW4XuS59XR91rGDDLcYXJ0oOlKrSD8 X-Received: by 2002:a17:902:e891:: with SMTP id w17mr29371814plg.160.1643791153315; Wed, 02 Feb 2022 00:39:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643791153; cv=none; d=google.com; s=arc-20160816; b=oAytdw5ytMV2xmc+Po8E/s9M0CzPqFTSbsAT4tXPDA6cnVl5N9AorCJmSu4MjebKaq Es3vfwyhf6No+0RCpsnKHsdRd1dNSMVnjwOKPiCrV47NnSoIKcI9+DIAh09KWTT67lm+ LotDqhaVr6xuDm+EV07UNx+9LDePU7NzQVQvmcTOGEbU+SMSkNkeyXKleZUtFWV8T/Mb c7qKM/aPb9UMKceeEPgIQGfF2AHRItdvhtI48hPLH9fMOhm2qHCKxSVC4sKkOGizXR4U gDxgjn/7DI+/ZR4cy8mdig1SnvnaQJsE7mKf/XThJVp8HFIaXKb2EScvUk/+mA2Nlw2j uG5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=UWLAYOgzUPAVYwRDb66uBOtLftLuQOweHkURJrUXNC0=; b=A8rXG1O5ZdgmJPp/HaASnnBnbOfvX52x8Kg6xN2+fAO/DmeGkiI2n+IDdD+V+CiIa4 jOe9vyrmIf7h+WRFa2RvqWAhALOuaWggjV3+OGeW20yQlrc47Jik7nYQ8WHWSxQcSOS1 oK3cuAnvQPKN1sCvUshAQkuHZqypax0MCiVsn+0IXa06jcvlYK7jPcgKxC8DVlTx7tE8 hPSPuJnpwMaazc972Mv+pR94iL3tDyo+UjRvwEibiDc9u7OETToHhXPz9YfHXnOS01KB 0r6qiTWms4AMGtEOqya4mlmp55aAYXd4wr8fTlFnx/wzy1I4coubXBhmHSGaS4XnUtpw Ee0A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=FUTn9VwB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l1si22274255plg.135.2022.02.02.00.39.01; Wed, 02 Feb 2022 00:39:13 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=FUTn9VwB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235791AbiBAI7U (ORCPT + 99 others); Tue, 1 Feb 2022 03:59:20 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:33422 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230333AbiBAI7U (ORCPT ); Tue, 1 Feb 2022 03:59:20 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 09169614ED for ; Tue, 1 Feb 2022 08:59:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7FAC2C340F3; Tue, 1 Feb 2022 08:58:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643705895; bh=r7eAvwcNoIC4Kqf/puxztITN9gelFA2bWYzMxyTBcqk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FUTn9VwBJk+gowjJncdfhI8YXGOVVoIvmYE9IzQqC9cdhW/cMO+e5VqWM30haDrIc U3FgJjjUJTNCNrZRZahJLZgeI0tlOZip0xbbil5ZXBz/XnAPlEHP+aSpYFeioDK5aS 3UY6EvPW3KtfatgAcmH3fEr1POVlk/KY/BZ7CD10WiX4vSdFlOR52JYAgs4YrGkw7a SRNG6rdPTssNKdXJmV14poc8ykiZcLknTdUDl8RRqOQWONsZTc7o4jATs5pHejPjJg 0aHc1ERZGT5SwWzdSSfYoIB3pwTAYz5/zFk6+Em53I4ru4ulTd0eT9MvNu1Gj+7FpI Re/uASIcXallw== Date: Tue, 1 Feb 2022 10:58:03 +0200 From: Mike Rapoport To: Michel Lespinasse Cc: 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: References: <20220128131006.67712-1-michel@lespinasse.org> <20220128131006.67712-34-michel@lespinasse.org> <20220131080729.GA785@lespinasse.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220131080729.GA785@lespinasse.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 31, 2022 at 12:07:29AM -0800, Michel Lespinasse wrote: > 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... Then maybe this unification can be done as the ground work for the speculative page fault handling? -- Sincerely yours, Mike.