Received: by 10.213.65.68 with SMTP id h4csp42618imn; Mon, 26 Mar 2018 14:40:39 -0700 (PDT) X-Google-Smtp-Source: AG47ELsoiDQLcA7xbNF9Rs5tdt+UiVuNVOlWNaIjA3Tbm0xsTsp8TIrbukdWTmg/El267801KV0Z X-Received: by 10.99.188.9 with SMTP id q9mr26192125pge.381.1522100439664; Mon, 26 Mar 2018 14:40:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522100439; cv=none; d=google.com; s=arc-20160816; b=OTY6kmWsBMnUryRaueP5B2QwAAPHShLCKQlrzLOL4/hnaQsRg3SuNAPf9R3x7YadT/ R0Bl8yEbf+p4AIvaq1gxgLnoBOH2tH42rlILu5lK9GnNl8s/bZvc020WivPZUjbW8c8T 9fLIzepcBvylsklkCv3j1v13/7lhLfHAFZDvZzEp2Ny+y5z7enuTYt3oEgU/zrA/kkLU 32wtkoSCXjD4K6wdlBVJogbOku4gwm5DNw48t2eppbGknAX/YCdb1eNLtGRGluXMYFbw bIYaOpgHB5iChV6zDWvuLnASPkxalkvwVFJZzo28iTrtzrXbUg2WH/HfffVrdfDA4mnz t1LQ== 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=VKlRZqKQpYxnQGm7r0Tdp3fh71XnIhBOa1yCudANvBc=; b=hlypMUGKHEP+OeHCG68HithKolXPlsC+YymdH0fxq6qARfvN42+Q/xrqtyn60pJccP EzHdSPukHN1OwXkQGj/zLIue9V+LSpurx1xCfm3KglKEApuPHs2fNKEwKH0x4ch8DDBH UYX51EhX+2lht9bstjondZwY8Ipxx6pucAA5GVt9WVSTYfB0ILa29vqPAUvBnJ3so1X6 FtvDqxV5t/3h16wK0Dfyl3WHTHuECC+mg45pVqgyuaeyP3+sAcejn7IemXvSh63pmOF1 3306Y6uEVI4gCXzVFXHkqB/gmmOyUexCFgc2iXP3Jxb+IMPGg55PZmiirsOtRnoFwVYT VvBg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=YTdcfzGQ; 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 e92-v6si15601670pld.736.2018.03.26.14.40.20; Mon, 26 Mar 2018 14:40:39 -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=YTdcfzGQ; 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 S1752160AbeCZVjW (ORCPT + 99 others); Mon, 26 Mar 2018 17:39:22 -0400 Received: from mail-pl0-f66.google.com ([209.85.160.66]:46372 "EHLO mail-pl0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751677AbeCZVjU (ORCPT ); Mon, 26 Mar 2018 17:39:20 -0400 Received: by mail-pl0-f66.google.com with SMTP id f5-v6so12762071plj.13 for ; Mon, 26 Mar 2018 14:39:20 -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=VKlRZqKQpYxnQGm7r0Tdp3fh71XnIhBOa1yCudANvBc=; b=YTdcfzGQyBMzy2yyfaAnW+vsL6SJLl76f9LRHcnsy3eYVMUqdGzuBYJIKcmLX94ikU vlG43QqVuw7TLeXq/y+uGKP/HFNaG4RU+1/RTRkI1bYenBTTt5Yxm+PwaPvgN2+1JuJM KkcpSqqro2jwQP1UajoJ/VTkDdRc4/9uBLuSi/PNQoOqHt+F2XX8lIzNzU2ZoWlSRpMu mvpJlN0By0NWSuxbFX2q2krfXCQhoTrBVGUBX+8iSY+wdlhjXGPZlzAdyxoXBpE3HDc5 FUpeoNDbGLnUTCELs9WKRqkEAzfVH632zSW6wAbqNZ53BHDMPovGwKchcU3rA11IqVjl 6cYg== 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=VKlRZqKQpYxnQGm7r0Tdp3fh71XnIhBOa1yCudANvBc=; b=r60t8nDzRYkpisTbrQ1UZNUUTCKV2WwEHrXJw3ggVs25gUQYYFR+QoMCwCHeIT1xYf QqBId0lbft0XneLwQr3hUamXQOnbkrzaQ2WBmrmnvptmnJTyQ1MhhxKljzkEyfJO8y8w DnWKIXEx82e40GRSWTDRQPSSdFaBP8XGypVVk+yCuCBL2l/FiUKO86wocFMmnMZpunMP ARre7jqTsMX8mRehTm2t1hfWbhWfP2jgRf2GlNd+rnxnFCjTH40tJFzpoz121qLgugpH 5ODk1LiwPv5SuDFTjTGg8DcjC/jw9J4J7MPzB1ZUrbIw889mGykDmXHYn74shJ9pU3a+ KxTw== X-Gm-Message-State: AElRT7Ea66zKLmoXJCI5j2lzW/NBV6gF1bd3c3aSBRErw5lSlTwKEfYW NsoBVI2Tfl7PwflT6Y729v+PeQ== X-Received: by 2002:a17:902:b40b:: with SMTP id x11-v6mr30985761plr.203.1522100359913; Mon, 26 Mar 2018 14:39:19 -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 h15sm30520626pfi.56.2018.03.26.14.39.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Mar 2018 14:39:19 -0700 (PDT) Date: Mon, 26 Mar 2018 14:39:18 -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 24/24] powerpc/mm: Add speculative page fault In-Reply-To: <1520963994-28477-25-git-send-email-ldufour@linux.vnet.ibm.com> Message-ID: References: <1520963994-28477-1-git-send-email-ldufour@linux.vnet.ibm.com> <1520963994-28477-25-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/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c > index 866446cf2d9a..104f3cc86b51 100644 > --- a/arch/powerpc/mm/fault.c > +++ b/arch/powerpc/mm/fault.c > @@ -392,6 +392,9 @@ static int __do_page_fault(struct pt_regs *regs, unsigned long address, > unsigned long error_code) > { > struct vm_area_struct * vma; > +#ifdef CONFIG_SPECULATIVE_PAGE_FAULT > + struct vm_area_struct *spf_vma = NULL; > +#endif > struct mm_struct *mm = current->mm; > unsigned int flags = FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE; > int is_exec = TRAP(regs) == 0x400; > @@ -459,6 +462,20 @@ static int __do_page_fault(struct pt_regs *regs, unsigned long address, > if (is_exec) > flags |= FAULT_FLAG_INSTRUCTION; > > +#ifdef CONFIG_SPECULATIVE_PAGE_FAULT > + if (is_user && (atomic_read(&mm->mm_users) > 1)) { > + /* let's try a speculative page fault without grabbing the > + * mmap_sem. > + */ > + fault = handle_speculative_fault(mm, address, flags, &spf_vma); > + if (!(fault & VM_FAULT_RETRY)) { > + perf_sw_event(PERF_COUNT_SW_SPF, 1, > + regs, address); > + goto done; > + } > + } > +#endif /* CONFIG_SPECULATIVE_PAGE_FAULT */ > + Can't you elimiate all #ifdef's in this patch if handle_speculative_fault() can be passed is_user and return some error code that fallback is needed? Maybe reuse VM_FAULT_FALLBACK? > /* When running in the kernel we expect faults to occur only to > * addresses in user space. All other faults represent errors in the > * kernel and should generate an OOPS. Unfortunately, in the case of an > @@ -489,7 +506,16 @@ static int __do_page_fault(struct pt_regs *regs, unsigned long address, > 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)) > return bad_area(regs, address); > if (likely(vma->vm_start <= address)) I think the code quality here could be improved such that you can pass mm, &spf_vma, and address and some helper function would return spf_vma if can_reuse_spf_vma() is true (and do *spf_vma to NULL) or otherwise return find_vma(mm, address). Also, spf_vma is being set to NULL because of VM_FAULT_RETRY, but does it make sense to retry handle_speculative_fault() in this case since we've dropped mm->mmap_sem and there may have been a writer queued behind it? > @@ -568,6 +594,9 @@ static int __do_page_fault(struct pt_regs *regs, unsigned long address, > > up_read(¤t->mm->mmap_sem); > > +#ifdef CONFIG_SPECULATIVE_PAGE_FAULT > +done: > +#endif > if (unlikely(fault & VM_FAULT_ERROR)) > return mm_fault_error(regs, address, fault); > And things like this are trivially handled by doing done: __maybe_unused