Received: by 10.192.165.148 with SMTP id m20csp414124imm; Thu, 3 May 2018 23:32:46 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoezIbbDgcELJ6UJBNY5kBv9Fmj7lEKDHO+u/FveFkiOv3IkjQ09L5MqtV4S9fzMlTfcVFT X-Received: by 10.98.32.199 with SMTP id m68mr4246485pfj.110.1525415566390; Thu, 03 May 2018 23:32:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525415566; cv=none; d=google.com; s=arc-20160816; b=zLeYsXQ4SgmX91obku45ddDS9Tq4ynsgxqczlZ0ADLiRFytxGUbZBNj9dOHVQLARJm UFbUxnDq4C+R3xvPLzEMumvLjauUKwe/JabNoVV2aIcHaN5ff4oyJyVTdbedDFuaHH+8 BjtZ9RSMC6NiOE0ZUav6etYZPU9txYutR18Q1sjMgBjjD9+OhD0h2BA0+572OqeSLUyg 6QcLePOpLRAd1dNGxB2Htc8Jq2PrPzRmH6JSH2tE+xY6rEexVpMlUeHHJKaC/jwJZkls GCDuD1bKYeqU5Jqre/BgC2Pn61Qlkh4JyRIGaia+Bs6ALIbV1z13vkeDwOP7M5rgtseg FR8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=vPrHK2R9Ee7THPsofigOviTHnP2p5+NMW1DcipcLpp0=; b=mSzBN7kL+EmrW7muerZe1M8Y7Rmdwv4impz0RFtvjr64A9QbLY/+KgqTsLudS9yzBx VxnTpgJrvIbhCKjVsILdarQo0T4DTR6tdgPdu60PsExTLQ+nVqA9WRF/lIDbuUcCen3+ wx2KaKwfki3baGgU7FUjCGaQq1j+BMWe0EZAYfHevMKx9GUwHRlg7lMOLISdWoyZ50v2 ILoQ20suk2lv/ab2HuOiCavXk57Q9R7Z/RUthObboGZNlzIqhHW6ij6crAiBYkOLg3/C esDM814suYRfQgcjMJ9oPQBRT/SrzmETULD6TKsR7F1Ac7pmEBiFMffjF+cH1dise1TO SCeA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=UzA5uefO; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j73si14915816pfa.297.2018.05.03.23.32.30; Thu, 03 May 2018 23:32:46 -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=@gmail.com header.s=20161025 header.b=UzA5uefO; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751283AbeEDGbJ (ORCPT + 99 others); Fri, 4 May 2018 02:31:09 -0400 Received: from mail-io0-f193.google.com ([209.85.223.193]:41067 "EHLO mail-io0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751002AbeEDGbI (ORCPT ); Fri, 4 May 2018 02:31:08 -0400 Received: by mail-io0-f193.google.com with SMTP id e12-v6so24447996iob.8 for ; Thu, 03 May 2018 23:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vPrHK2R9Ee7THPsofigOviTHnP2p5+NMW1DcipcLpp0=; b=UzA5uefOedQ1Fy2rMxsXgUxQdSSwJDud74HtH7qdI3S/RC+SU7O+EIYirWFEDWjquh uR7L84ZAnpPDwo6ENuDd9IJjWmrxLbhkVjEQq0ySgvpOiE/3grNmuwg5cCRnsaAcjDK7 b7UwDXL1iqMZG2n3DgkaL2yQvbedR2VY6GliV9fsVNda+lVSqDleki+JY+NoG96ewM0o PFEQ9bDcgvQZ0lthRKYoJpeOYXci0zdLl/AxoeV9t2HX1GVK4KE/oGTNe7nxCM6BlSTz mKtsJtLZqkYGgRyWT22eNJkhGYRmPsd7j6AWKfrDhDcg+b/v98KphakQzvvq9q6X1o7B YskQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vPrHK2R9Ee7THPsofigOviTHnP2p5+NMW1DcipcLpp0=; b=O2yjoDYDFtY7LIzbzZf+3wQ7AJopGlqWClCxc4RCaWOoMM2+xjT7k8oXsklMevDA0Q WAM3BBSu1wwAHpUNV7skjGjgQ/r0Hs4d/dPUTBl6UdqO19J6E8yuSmFl5rCl8COy2ekJ 9TJxR7QxxuCRdCKUCiepb41fLekX+OmPOMm9BTqSTiUrUbQMKq7HrlMyTVM0ydLrUkVQ 73KK3HgtuZ+pMzbl+VyShab/3qg/Ix8jiGAhc1EgId63idWsldVBGW6P1kbT5FB9M2cQ f7+XJMqsTUJnLFMc1mO6A5VenAnHuU8EyKJeixLkYlGM+l/CPDLLXqcker30VDpdpfFM 2zsQ== X-Gm-Message-State: ALQs6tC6I2dDy7sUmJtGtuSZ5AUnHrHJL/L/ZAuI89ZQ0lLceCDI03fx TSva2XhVxzuvN23pRycwGpaFTBWq3DHXoq/8EkQ= X-Received: by 2002:a6b:307:: with SMTP id 7-v6mr29619313iod.66.1525415468071; Thu, 03 May 2018 23:31:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.140.23 with HTTP; Thu, 3 May 2018 23:31:07 -0700 (PDT) In-Reply-To: <871seunmj9.fsf@e105922-lin.cambridge.arm.com> References: <1525247672-2165-1-git-send-email-opensource.ganesh@gmail.com> <1525247672-2165-2-git-send-email-opensource.ganesh@gmail.com> <871seunmj9.fsf@e105922-lin.cambridge.arm.com> From: Ganesh Mahendran Date: Fri, 4 May 2018 14:31:07 +0800 Message-ID: Subject: Re: [PATCH 2/2] arm64/mm: add speculative page fault To: Punit Agrawal Cc: Laurent Dufour , Catalin Marinas , Will Deacon , linux-arm-kernel@lists.infradead.org, linux-kernel , Linux-MM Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2018-05-02 22:46 GMT+08:00 Punit Agrawal : > Hi Ganesh, > > I was looking at evaluating speculative page fault handling on arm64 and > noticed your patch. > > Some comments below - Thanks for your review. > > Ganesh Mahendran writes: > >> This patch enables the speculative page fault on the arm64 >> architecture. >> >> I completed spf porting in 4.9. From the test result, >> we can see app launching time improved by about 10% in average. >> For the apps which have more than 50 threads, 15% or even more >> improvement can be got. >> >> Signed-off-by: Ganesh Mahendran >> --- >> This patch is on top of Laurent's v10 spf >> --- >> arch/arm64/mm/fault.c | 38 +++++++++++++++++++++++++++++++++++--- >> 1 file changed, 35 insertions(+), 3 deletions(-) >> >> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c >> index 4165485..e7992a3 100644 >> --- a/arch/arm64/mm/fault.c >> +++ b/arch/arm64/mm/fault.c >> @@ -322,11 +322,13 @@ static void do_bad_area(unsigned long addr, unsigned int esr, struct pt_regs *re >> >> static int __do_page_fault(struct mm_struct *mm, unsigned long addr, >> unsigned int mm_flags, unsigned long vm_flags, >> - struct task_struct *tsk) >> + struct task_struct *tsk, struct vm_area_struct *vma) >> { >> - struct vm_area_struct *vma; >> int fault; >> >> + if (!vma || !can_reuse_spf_vma(vma, addr)) >> + vma = find_vma(mm, addr); >> + > > It would be better to move this hunk to do_page_fault(). > > It'll help localise the fact that handle_speculative_fault() is a > stateful call which needs a corresponding can_reuse_spf_vma() to > properly update the vma reference counting. Yes, your suggestion is better. > > >> vma = find_vma(mm, addr); > > Remember to drop this call in the next version. As it stands the call > the find_vma() needlessly gets duplicated. Will fix > >> fault = VM_FAULT_BADMAP; >> if (unlikely(!vma)) >> @@ -371,6 +373,7 @@ static int __kprobes do_page_fault(unsigned long addr, unsigned int esr, >> int fault, major = 0; >> unsigned long vm_flags = VM_READ | VM_WRITE; >> unsigned int mm_flags = FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE; >> + struct vm_area_struct *vma; >> >> if (notify_page_fault(regs, esr)) >> return 0; >> @@ -409,6 +412,25 @@ static int __kprobes do_page_fault(unsigned long addr, unsigned int esr, >> >> perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, addr); >> >> + if (IS_ENABLED(CONFIG_SPECULATIVE_PAGE_FAULT)) { > > You don't need the IS_ENABLED() check. The alternate implementation of > handle_speculative_fault() when CONFIG_SPECULATIVE_PAGE_FAULT is not > enabled takes care of this. Will fix > >> + fault = handle_speculative_fault(mm, addr, mm_flags, &vma); >> + /* >> + * Page fault is done if VM_FAULT_RETRY is not returned. >> + * But if the memory protection keys are active, we don't know >> + * if the fault is due to key mistmatch or due to a >> + * classic protection check. >> + * To differentiate that, we will need the VMA we no >> + * more have, so let's retry with the mmap_sem held. >> + */ > > As there is no support for memory protection keys on arm64 most of this > comment can be dropped. will fix > >> + if (fault != VM_FAULT_RETRY && >> + fault != VM_FAULT_SIGSEGV) { > > Not sure if you need the VM_FAULT_SIGSEGV here. > >> + perf_sw_event(PERF_COUNT_SW_SPF, 1, regs, addr); >> + goto done; >> + } >> + } else { >> + vma = NULL; >> + } >> + > > If vma is initiliased to NULL during declaration, the else part can be > dropped. will fix > >> /* >> * As per x86, we may deadlock here. However, since the kernel only >> * validly references user space from well defined areas of the code, >> @@ -431,7 +453,7 @@ static int __kprobes do_page_fault(unsigned long addr, unsigned int esr, >> #endif >> } >> >> - fault = __do_page_fault(mm, addr, mm_flags, vm_flags, tsk); >> + fault = __do_page_fault(mm, addr, mm_flags, vm_flags, tsk, vma); >> major |= fault & VM_FAULT_MAJOR; >> >> if (fault & VM_FAULT_RETRY) { >> @@ -454,11 +476,21 @@ static int __kprobes do_page_fault(unsigned long addr, unsigned int esr, >> if (mm_flags & FAULT_FLAG_ALLOW_RETRY) { >> mm_flags &= ~FAULT_FLAG_ALLOW_RETRY; >> mm_flags |= FAULT_FLAG_TRIED; >> + >> + /* >> + * Do not try to reuse this vma and fetch it >> + * again since we will release the mmap_sem. >> + */ >> + if (IS_ENABLED(CONFIG_SPECULATIVE_PAGE_FAULT)) >> + vma = NULL; > > Please drop the IS_ENABLED() check. will fix > > Thanks, > Punit > >> + >> goto retry; >> } >> } >> up_read(&mm->mmap_sem); >> >> +done: >> + >> /* >> * Handle the "normal" (no error) case first. >> */