Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp353289pxb; Mon, 7 Feb 2022 13:00:50 -0800 (PST) X-Google-Smtp-Source: ABdhPJzbttnMmj6KKgqu4k9stYoZqfn+wya1db+/O/pxsfctloa5pnGhnz28Q7vc6pGygENnGKNV X-Received: by 2002:aa7:c043:: with SMTP id k3mr1303065edo.184.1644267650783; Mon, 07 Feb 2022 13:00:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644267650; cv=none; d=google.com; s=arc-20160816; b=eMwbMNihRx3WCnaxnOStOZtzFIvHVINzmjRD38C3aLgbPF8bKmPwfDxND9e9bsYyLV idry9rZjZBdvqvzvEMmPxomZ3ChUSTlPvASmTa4ThTtNlGRkPj5XPPMqrOQ0dYAzXdO7 W92wx74T6pmY7RkmDhy0Xo9KK1hh2rZRWp5kL9buExBBYsCrgMEXrw1+RWcXIYUmzsyi WMD/lT2UpHr3GJxeEpBysUjlHtKGIE7ccEnGfUZVZ/eQCb7oiXum3zEAcBTEX5/Xjrzn D6PGmZSdTajbotit2vgJwcgG829Hx3CnQYJ+f6Sf8e8AuSC92OsUUqJFPw8op5AbcQdP JIyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature:dkim-signature; bh=1OcmxJk2OvDWG73G4pAq7/+nlEvhi8aORC9/Xya6+Ls=; b=vIvzFOt8PfztqzNZASEf8Po3jaIYsvMugIegLt80sA4naOUHjQSaJ580GbxWM/lQP/ CWfvdOpsghgVezkiRflc5E9jaxjajE8xMYJ7H+un+kEO4W8D8ugxWzVVHysVIgNMWvXm pyLveLbq1zz+DJh6YWmrtNq0ZKiAQXQRHAjkp1MS8/dOSNBWE6k5/OQpGUTe2vjuGYK0 iIyZ2DCRIo+3/m+lochGSUIsZ5+P1QMSXcQVc/e3UYZWeRTValwWdtq4HDkt9Rglz3yf yXrhsjkoQwekKRk2t/G+/WMbwYPfgW8EB3yT+EFrTAJ9vSJS24x8Qf73piBNUA9bmrXq gSDw== ARC-Authentication-Results: i=1; mx.google.com; dkim=neutral (no key) header.i=@lespinasse.org header.s=srv-54-ed header.b=skJSYiER; dkim=pass (test mode) header.i=@lespinasse.org header.s=srv-54-rsa header.b=eoc8p5YN; 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=lespinasse.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h25si3063183edw.529.2022.02.07.13.00.25; Mon, 07 Feb 2022 13:00:50 -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=neutral (no key) header.i=@lespinasse.org header.s=srv-54-ed header.b=skJSYiER; dkim=pass (test mode) header.i=@lespinasse.org header.s=srv-54-rsa header.b=eoc8p5YN; 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=lespinasse.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345781AbiBGRqc (ORCPT + 99 others); Mon, 7 Feb 2022 12:46:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57250 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239819AbiBGRj1 (ORCPT ); Mon, 7 Feb 2022 12:39:27 -0500 Received: from server.lespinasse.org (server.lespinasse.org [IPv6:2001:470:82ab::100:0]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D1C11C0401E3 for ; Mon, 7 Feb 2022 09:39:19 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=lespinasse.org; i=@lespinasse.org; q=dns/txt; s=srv-54-ed; t=1644255559; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to : from; bh=1OcmxJk2OvDWG73G4pAq7/+nlEvhi8aORC9/Xya6+Ls=; b=skJSYiEROeRdLBRvlg5uybRGp9cxiPOKmua/5/VrltRlMb6TSofYBeJaX9ZUGyAg1Lnjr ZIxdfMW+DHN9/7lDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lespinasse.org; i=@lespinasse.org; q=dns/txt; s=srv-54-rsa; t=1644255559; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to : from; bh=1OcmxJk2OvDWG73G4pAq7/+nlEvhi8aORC9/Xya6+Ls=; b=eoc8p5YNoCReCw2EZOIOZwfKnoffU/z/CN964bhabcwmhMHeL7t14l9bVDyMTWjNehndB qd4Lc9709tXxILj3O7IjfauU9rADrt4mpBVVuL5Oo7G69azMohTm/LPOItq8jf0hq4LfqhP llWMpGgK8c2qLfl0Unu0gFUAWo/6/UTaAjI5o8C2T9NUE4Hteln+3kRi0G31ti/vEdLuURm 9KtpOqbv1sAdxEq7ZXK7A3ztUlpWE4Stwv2p7dVlniP9Os7v37/MCpLOTDOeSAP28DsZnkr ddwAN/Ibr6Rv4l8fNwKMn50WReE6lqznnEqbqyw0kw489WxtL5UIVg9Ro+vA== Received: by server.lespinasse.org (Postfix, from userid 1000) id 6D766160B2F; Mon, 7 Feb 2022 09:39:19 -0800 (PST) Date: Mon, 7 Feb 2022 09:39:19 -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: <20220207173919.GB12302@lespinasse.org> 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: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 01, 2022 at 10:58:03AM +0200, Mike Rapoport wrote: > 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? I feel like this is quite unrelated, and that introducing such artificial dependencies is a bad work habit we have here in linux MM... That said, unifying the PF code between archs would be an interesting project on its own. The way I see it, there could be a unified page fault handler, with some arch specific parts defined as inline functions. I can see myself making an x86/arm64/powerpc initial proposal if there is enough interest for it, but I'm not sure how extending it to more exotic archs would go - I think this would have to involve arch maintainers at least for testing purposes, and I'm not sure if they'd have any bandwidth for such a project... -- Michel "walken" Lespinasse