Received: by 10.213.65.68 with SMTP id h4csp44373imn; Mon, 26 Mar 2018 14:43:34 -0700 (PDT) X-Google-Smtp-Source: AIpwx49Bg8OjeGvPi8eZsXtCBMqFL5sQjJIUcxW5FEZbQy0ZflFUDiy3bCs/vaYIc9oVDvtVxdMW X-Received: by 2002:a17:902:b901:: with SMTP id bf1-v6mr3663415plb.74.1522100614372; Mon, 26 Mar 2018 14:43:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522100614; cv=none; d=google.com; s=arc-20160816; b=OPi5oGEBZvliXnuks8Ryw96DJE2LkBn/lKh/mUrpbgLL8MPwz2D+QXTz1nl2Me0Vut JFOagJ2FHGqCv+K8swJkEh68e53OFl++EDsGFs+x9Oihu5C+f1wyePf74DfNzKioMffQ 2OFZajMLYTPYrIqoGqxdsdSYJVXZq1kVnmIQVYgayj/I8r7yWkrHu2NeYH1E3tmimUN5 qW2/TG/PvnJKXIfqWgCVvDd/dEOZ0/vPMu50wR2HznxHxRjuN+OIN5wYgyGRWGL4a/EN GpcgW38DfyuKaV63zqmDiPoRr58hS68HBo33kf17bKPCpajnNX6FjSp3hhVoBNrJz/YE +YHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=vIYJyKY6sWWvY2342WiN8wkTVo2kMi09oBRPO7OrDyU=; b=YcQ3Trbj2PVxfVP0tyNOMOX5blbarlx+JPTcI9vaDbsokREq/qnsQ+qX8vb0sZR+tL 6td36Nd4FKzvDRD042MWQA+4fW/7VOtrq6hwv7cI5HlDxvF+e1bTOillzPeqPbX/frnE h769hOqhn0LHvRcbk5XyO7TbbnjTcfmXdktBdnzB2rPSljtT4oeYkWNmacGt1Rt3yNmQ ddrtjgT8ZEyhct78DfKkmj6TBk8yBmxs/j8x7etfW/d5qhjY5WVylqJ741Ea0g3v7zXu 1iiygzgczlo8mnawC/7/pOsQxnDQZ4rze25b4wjqolV3g3YUv84JFDnb3eDdHeQk3YL6 /2Kg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=bt9Xak3B; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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. [209.132.180.67]) by mx.google.com with ESMTP id a60-v6si15044898pli.13.2018.03.26.14.43.19; Mon, 26 Mar 2018 14:43:34 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=bt9Xak3B; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 S1752481AbeCZVl1 (ORCPT + 99 others); Mon, 26 Mar 2018 17:41:27 -0400 Received: from mail-pl0-f65.google.com ([209.85.160.65]:33194 "EHLO mail-pl0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752458AbeCZVlZ (ORCPT ); Mon, 26 Mar 2018 17:41:25 -0400 Received: by mail-pl0-f65.google.com with SMTP id c11-v6so12783302plo.0 for ; Mon, 26 Mar 2018 14:41:25 -0700 (PDT) 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=vIYJyKY6sWWvY2342WiN8wkTVo2kMi09oBRPO7OrDyU=; b=bt9Xak3Bqhx3RvR+dU8HDKTurFOzQlSa12R57FViobDUpCMxvtz5E0TPUkZNcj1geL kZ1H/UgIkcWwV3onKjIR72qGYRSV8s6HSbbFNF4EPDmY5nA65Gh6Sd8gL9wgLu+G6SDi 8TqpmPYxnWS+MEL7B3XiSF2ndjeF3O8PusM8PWuYhIICK1HordyS/YEcCmEwzE3VJFRU xA/SR0vAIofW3xANC/Vt0SkMLYJh/CqiW///I6u7eUvg4irOhf0KCj8xHe523RnJpRWR eDX9cbitHqIb/Bc1qD8/5pesEXywXkN5yoRHpKJITXBBo0imPrVOx/4oPMQdeZEl+n5q BwOA== 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=vIYJyKY6sWWvY2342WiN8wkTVo2kMi09oBRPO7OrDyU=; b=d0C1pdHrhRfTHfqOrCdWaFhRqdNjaofOACxoGHcbTrmr3FFy0KqXATqc7dE2bbMwUm TsnkM9c6KZAbi5IfRxTzjFuDK4n5GNk0hXgraPRPtQRq4jk0uBhZQ3ISG2aoK6kCoP7L bd4infx0KhqmCQ+2nwQxARiff44AsJidos1vuaM4j67b3c0zbOthyuBUjOGopaftLiST gFA4jfeSAV4NZ99lEsm5flf61HbbK+znNCh8HwX07L3n7U4Sv5UNHuaGCQZCfJqxWSdW lI7gG9Vx2aoJyeKMmy+kdiiOUBJ85+We9N8fc7bsa9LWaeEtuUrUftS7FoLgzBbkX6iw p7Lw== X-Gm-Message-State: AElRT7GUQGH4/MnEoqAfPts9rj0pNt7DQzUqvNgC4RpzfYw2Z00DCpJm 8aplLhmq/+GLXig1cTruIs1VeQ== X-Received: by 2002:a17:902:57d2:: with SMTP id g18-v6mr30077099plj.381.1522100484915; Mon, 26 Mar 2018 14:41:24 -0700 (PDT) Received: from [2620:15c:17:3:3a5:23a7:5e32:4598] ([2620:15c:17:3:3a5:23a7:5e32:4598]) by smtp.gmail.com with ESMTPSA id v68sm32326803pfv.85.2018.03.26.14.41.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Mar 2018 14:41:24 -0700 (PDT) Date: Mon, 26 Mar 2018 14:41:23 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Laurent Dufour cc: paulmck@linux.vnet.ibm.com, peterz@infradead.org, akpm@linux-foundation.org, kirill@shutemov.name, ak@linux.intel.com, mhocko@kernel.org, dave@stgolabs.net, jack@suse.cz, Matthew Wilcox , benh@kernel.crashing.org, mpe@ellerman.id.au, paulus@samba.org, Thomas Gleixner , Ingo Molnar , hpa@zytor.com, Will Deacon , Sergey Senozhatsky , Andrea Arcangeli , Alexei Starovoitov , kemi.wang@intel.com, sergey.senozhatsky.work@gmail.com, Daniel Jordan , linux-kernel@vger.kernel.org, linux-mm@kvack.org, haren@linux.vnet.ibm.com, khandual@linux.vnet.ibm.com, npiggin@gmail.com, bsingharora@gmail.com, Tim Chen , linuxppc-dev@lists.ozlabs.org, x86@kernel.org Subject: Re: [PATCH v9 23/24] x86/mm: Add speculative pagefault handling In-Reply-To: <1520963994-28477-24-git-send-email-ldufour@linux.vnet.ibm.com> Message-ID: References: <1520963994-28477-1-git-send-email-ldufour@linux.vnet.ibm.com> <1520963994-28477-24-git-send-email-ldufour@linux.vnet.ibm.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 13 Mar 2018, Laurent Dufour wrote: > diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c > index e6af2b464c3d..a73cf227edd6 100644 > --- a/arch/x86/mm/fault.c > +++ b/arch/x86/mm/fault.c > @@ -1239,6 +1239,9 @@ __do_page_fault(struct pt_regs *regs, unsigned long error_code, > unsigned long address) > { > struct vm_area_struct *vma; > +#ifdef CONFIG_SPECULATIVE_PAGE_FAULT > + struct vm_area_struct *spf_vma = NULL; > +#endif > struct task_struct *tsk; > struct mm_struct *mm; > int fault, major = 0; > @@ -1332,6 +1335,27 @@ __do_page_fault(struct pt_regs *regs, unsigned long error_code, > if (error_code & X86_PF_INSTR) > flags |= FAULT_FLAG_INSTRUCTION; > > +#ifdef CONFIG_SPECULATIVE_PAGE_FAULT > + if ((error_code & X86_PF_USER) && (atomic_read(&mm->mm_users) > 1)) { > + fault = handle_speculative_fault(mm, address, flags, > + &spf_vma); > + > + if (!(fault & VM_FAULT_RETRY)) { > + if (!(fault & VM_FAULT_ERROR)) { > + perf_sw_event(PERF_COUNT_SW_SPF, 1, > + regs, address); > + goto done; > + } > + /* > + * In case of error we need the pkey value, but > + * can't get it from the spf_vma as it is only returned > + * when VM_FAULT_RETRY is returned. So we have to > + * retry the page fault with the mmap_sem grabbed. > + */ > + } > + } > +#endif /* CONFIG_SPECULATIVE_PAGE_FAULT */ All the comments from the powerpc version will apply here as well, the only interesting point is whether VM_FAULT_FALLBACK can be returned from handle_speculative_fault() to indicate its not possible. > + > /* > * When running in the kernel we expect faults to occur only to > * addresses in user space. All other faults represent errors in > @@ -1365,7 +1389,16 @@ __do_page_fault(struct pt_regs *regs, unsigned long error_code, > might_sleep(); > } > > - vma = find_vma(mm, address); > +#ifdef CONFIG_SPECULATIVE_PAGE_FAULT > + if (spf_vma) { > + if (can_reuse_spf_vma(spf_vma, address)) > + vma = spf_vma; > + else > + vma = find_vma(mm, address); > + spf_vma = NULL; > + } else > +#endif > + vma = find_vma(mm, address); > if (unlikely(!vma)) { > bad_area(regs, error_code, address); > return; > @@ -1451,6 +1484,9 @@ __do_page_fault(struct pt_regs *regs, unsigned long error_code, > return; > } > > +#ifdef CONFIG_SPECULATIVE_PAGE_FAULT > +done: > +#endif > /* > * Major/minor page fault accounting. If any of the events > * returned VM_FAULT_MAJOR, we account it as a major fault.