Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp514662pxb; Wed, 27 Jan 2021 13:33:51 -0800 (PST) X-Google-Smtp-Source: ABdhPJwfBmopYxUrOcoBdvh1XLiMbHhCnY9EC2Jt4tqj3RH90BT6884FZTZt15N71Ziz2Rv/P9pw X-Received: by 2002:a05:6402:2d2:: with SMTP id b18mr10994893edx.228.1611783231415; Wed, 27 Jan 2021 13:33:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611783231; cv=none; d=google.com; s=arc-20160816; b=MRYl6K9uAjhc15THcBw/7pDv+yjQ7qC2K1MMM/O79sIg6ZPNCsMRMqLID+5tlZSmdM VGmNYcR3olIv4Ur0EG0zBA4m4s/PM3v69QUXH0UU3qrSULVKFolbYrLMv0BIe2aLx0vT k9TyaIqiXYzNeYcW9gYqjLIXvkjhxiBzF+O6BYGtURxkYc3gtNioOTbC4SWJ7fumZCeY 1wILDVyYgX8sgetYMdbgwuDNGcbCOpS9cyMLmo0TRf8evQCQnObfnfUzUBtJ9ukUP3Mc Hq764T2XmTsRJE8QpNIdEwY1+kqeNAM384maOn1sWBjnXGMm4b5vOXI737fPbHjyRYw4 23vw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date:dkim-signature; bh=6elxq1WfF4E41ZiBczRrJyQmMODP+O0N7PSHZ9Kx/14=; b=GLVAD0OoO+Fa/pHnr8TOU7/Q5AXqbTWHMiFbP7lPPaKZ4GKf7Hf1y1FowVJZPG5hPs W8B+v5+SYOCMNGWA6CwGH6bIgmJ9I9OrU+6AbGuxKbf9MukRV8HUjPqnqmB/hj1cteNa 90ztpFr7x8mMoDAHAuHIhO5xB+jBNWK1CK9/rvvhtyLdcfC004qFNiAAaYKg5wfp3WPA SAIjkMrE/dN2L3prE9h7T+/Lp3DXX/Cf+BLeMtKioD9NFBCydGLKSokXUC4u40hJiJK4 O+1AwrpWSHbClDpWoctqMGgh6eK8G+ByapChHOROh7ZFeyZtn1xOD5w/Khhn62cDk/bo qXGA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=AuzqKJ94; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c24si1365523eja.436.2021.01.27.13.33.25; Wed, 27 Jan 2021 13:33:51 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=AuzqKJ94; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234316AbhA0Hd4 (ORCPT + 99 others); Wed, 27 Jan 2021 02:33:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56392 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S317488AbhA0AEF (ORCPT ); Tue, 26 Jan 2021 19:04:05 -0500 Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 18D57C061353 for ; Tue, 26 Jan 2021 15:28:47 -0800 (PST) Received: by mail-oi1-x22d.google.com with SMTP id n7so177097oic.11 for ; Tue, 26 Jan 2021 15:28:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=6elxq1WfF4E41ZiBczRrJyQmMODP+O0N7PSHZ9Kx/14=; b=AuzqKJ94rmZ3lCpEcfqI5NsAgVFHvpLo6cHeoOZKK/GpHi6W5cv3GwWc6hUhWxBxnv WHCl6R8Q+Os3QUsUOQJA50Q5YtBvL1jUO3gD3ZEWyZgsrxvaGn+kW9I4nKieg397ml3d 38Rq/CmX7T4sjBr5YoOrSFTHZEnnDn5QzNJrGeI1A36VRJdy6lcI77reKvNjyjPus1gB N0JBff//11xHi07IYuRyWz0OP8qcIhCF6prjSNziTmSLOUE/X5F3dJUx8vzqefTR/XAx o99ujyveMc11O005JQmFa28uLzKVvlSaHYrv3F0IcWmlmfrdavEpVFEZg6qyynYxcezE 31Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=6elxq1WfF4E41ZiBczRrJyQmMODP+O0N7PSHZ9Kx/14=; b=uWsK7aqMyDVBuV7tXAe2zMAV9EBgo6d0i3J5hZC5sXNNhePyCW+vxB7FKx95c/Ek0b +xnFpCj7PN5CiLTIIXegZGUcIHl+ASQAVsKqguTZsujopQ7J30/j77lUJ1njNxsgt6x0 MbVR6EwGYFIqAwPKb1+PLWzF4Hrv730PhCUVvC/Cv1bzYN62l2xwcZuOn207qwYaZemf 1R60zNgP1U1n6yvuNVt/C0r3NvyTIjG+Y3MR2qMInrEkjD9WWL503BxvwVRuqSoZfwm/ eff3/Xr/ArS9Z+Jb94q/OFzUPKlliTPoCn4Ed2xcYMMOPVbN+fgAbfh2OyxmWPq1gQs5 p3/A== X-Gm-Message-State: AOAM531XvM58UOeAQo9eYRRILFqx1Zsxuz8LYe/2Du68xVBCQrpxN7Hx cAf+TkR851FN0+5YDd0hL5a00lSfGoS/oA== X-Received: by 2002:aca:ecc8:: with SMTP id k191mr1341900oih.179.1611703725081; Tue, 26 Jan 2021 15:28:45 -0800 (PST) Received: from eggly.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id g13sm26718otl.60.2021.01.26.15.28.43 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Tue, 26 Jan 2021 15:28:44 -0800 (PST) Date: Tue, 26 Jan 2021 15:28:22 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Will Deacon cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, Catalin Marinas , Jan Kara , Minchan Kim , Andrew Morton , "Kirill A . Shutemov" , Linus Torvalds , Vinayak Menon , Hugh Dickins , Nick Desaulniers , kernel-team@android.com Subject: Re: [PATCH v4 0/8] Create 'old' ptes for faultaround mappings on arm64 with hardware access flag In-Reply-To: <20210126230851.GE30941@willie-the-truck> Message-ID: References: <20210120173612.20913-1-will@kernel.org> <20210126230851.GE30941@willie-the-truck> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 26 Jan 2021, Will Deacon wrote: > On Wed, Jan 20, 2021 at 05:36:04PM +0000, Will Deacon wrote: > > Hi all, > > > > This is version four of the patches I previously posted here: > > > > v1: https://lore.kernel.org/r/20201209163950.8494-1-will@kernel.org > > v2: https://lore.kernel.org/r/20210108171517.5290-1-will@kernel.org > > v3: https://lore.kernel.org/r/20210114175934.13070-1-will@kernel.org > > > > The patches allow architectures to opt-in at runtime for faultaround > > mappings to be created as 'old' instead of 'young'. Although there have > > been previous attempts at this, they failed either because the decision > > was deferred to userspace [1] or because it was done unconditionally and > > shown to regress benchmarks for particular architectures [2]. > > > > The big change since v3 is that the immutable fields of 'struct vm_fault' > > now live in a 'const' anonymous struct. Although Clang will silently > > accept modifications to these fields [3], GCC emits an error. The > > resulting diffstat is _considerably_ more manageable with this approach. > > The only changes I have pending against this series are cosmetic (commit > logs). Can I go ahead and queue this in the arm64 tree so that it can sit > in linux-next for a bit? (positive or negative feedback appreciated!). That would be fine by me: I ran v3 on rc3, then the nicer smaller v4 on rc4, and saw no problems when running either of them (x86_64 only). Hugh