Received: by 10.192.165.148 with SMTP id m20csp409070imm; Thu, 3 May 2018 23:26:01 -0700 (PDT) X-Google-Smtp-Source: AB8JxZr9yCky8CE15QY2pClPYBNatEZyKy6/zViyCMLBaDymA3BGPlQZucA5KMuhLcXiLivFzdGR X-Received: by 10.98.204.8 with SMTP id a8mr25589851pfg.219.1525415161823; Thu, 03 May 2018 23:26:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525415161; cv=none; d=google.com; s=arc-20160816; b=zbaGpu3+nkKrZ+nVSi5DvJnlKNqBSzBK1MI+VSkAqwwkT/39RRA1u2QIpGzs+Gqn5u RbyEfcOE+ErvOrEsPWG4TYSunVSYitE0J4bW7hP4pk4Eiofkr/3TtUsqyfxfQW6O0cud RKWcfFIkoIkg9chaIByp3tg2JEvYQKIs8Byi4BV5s9zmMJjVmhebfA0ilq+N5Fwv45rL T7FQG5zVxjNmEdFGVcJ5bsatEujC04uLsWz0SFNokeweIKv99Ve6gEsId+tLRLdKOode G2oj63x3DpCXgtQ6kRU6/7ClBEmGnI73RJUKEzZw4q530Ta4tqpdq8zpdgKkxLwKKnjY MTew== 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=vNExSxf/j8z0FRbZxxuYKlTU23PfnxR97uMtlbD/cWQ=; b=cIOu6cQmiZN/q21trNxxVETUNQjlNzWLOQHJgx3pLvN3a5syyv5fCde4xHGm5DrRWJ br16k0SVKIEdjgokwVtKPjjezuWLJu5+us9XgFwYhISyFk0l/npaL/LmR22EW06LRYXa WLvZx4pVdMKjAEUMkDPwbPVOLq4zIpXlovoDY5j8v5Cd2ZEflYVz3Y4zA8nO3o7KsBcW LDDQcLSoDe4mGj7di+Suyin6h7xDoAXCmZlzie1Fkp2PuXl1GeTmmrgt5IYloe8bW0Vu UFhGuaQFGDuABcF9H6Aq5B2OLr+sWrp+d7IuQzjQLx3ZlpUpb+y0E6h7EZrUAzKYs20r h5+A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Am8LrhBG; 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.25.33; Thu, 03 May 2018 23:26:01 -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=Am8LrhBG; 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 S1751349AbeEDGZW (ORCPT + 99 others); Fri, 4 May 2018 02:25:22 -0400 Received: from mail-it0-f66.google.com ([209.85.214.66]:54616 "EHLO mail-it0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751002AbeEDGZU (ORCPT ); Fri, 4 May 2018 02:25:20 -0400 Received: by mail-it0-f66.google.com with SMTP id z6-v6so2084167iti.4 for ; Thu, 03 May 2018 23:25:20 -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=vNExSxf/j8z0FRbZxxuYKlTU23PfnxR97uMtlbD/cWQ=; b=Am8LrhBGvywO6PLs/VPo5ktlJ+zlNO5CFFjaEO3wpwaoIB8hKDHcrJ6o2ZNfvo9XcN dlU4cO0VeBvLDvsdxMhxixE1GpU4GckokKyVbqaXlCebBWBiXL0TUasPJHYHuj04WFsO +SOMGDlIexUe9mLPgDLMTY/6enqGYunA0e4hv65SS7tnoRfaL7AJaZiBwATGF4UjuIYC umBm+U+nJNef2aCR7K3Tn97pWwCftPvIVIeIRlkeLqh76GOjlXzhgOzbPXd6kRlPmC32 3SvRlHKBFObhGraARknVhDDy89MfIfsybKE4uqEXSWMM2kjFXXns6Scri+LSZ4QRq/KM ulLQ== 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=vNExSxf/j8z0FRbZxxuYKlTU23PfnxR97uMtlbD/cWQ=; b=gVl+4uLMg1aiWvgJVtaBEh++yuwgEEStH+P/m+C9n1/2iS9+Z/K5/Zu0gYdHmzCo+g b5dayttw77CCX7Q6FZX/2miWZrEgRLBBxhTBF7R79w2aiH6v655V9CszeHNopDa/3n0S wEJsShhsOHu9i8HkJZDh6UgLC8f6n/dvb52ApgBFTiuvor2Wp+B/Ghr/BwCTyQpaONeF q1wvF6OhJBBP7/FuTmnZ31E0I3em9wdRElVQ+ICUKhTBufs/pSP7J/0DcAGYllBhIu5k vuYmLLGUN8h91gwo4jUTrIgiiF/QmB8jOiTQzmR85nbuCJafHg9CvV0EUnsIhxqLO6d5 01dg== X-Gm-Message-State: ALQs6tAwsllqumSRMsg3igsFiOWZXd4dalQDq08f+hWXIuoceXrlprL5 GoTejwsHwmAX7wrdXRyP0sa8Jxyex+KIcz8Pa6o= X-Received: by 2002:a24:e3c7:: with SMTP id d190-v6mr27944768ith.22.1525415120038; Thu, 03 May 2018 23:25:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.140.23 with HTTP; Thu, 3 May 2018 23:25:19 -0700 (PDT) In-Reply-To: <9e7ab02c-a9af-71ed-afda-108e3b26b2ef@linux.vnet.ibm.com> References: <1525247672-2165-1-git-send-email-opensource.ganesh@gmail.com> <1525247672-2165-2-git-send-email-opensource.ganesh@gmail.com> <9e7ab02c-a9af-71ed-afda-108e3b26b2ef@linux.vnet.ibm.com> From: Ganesh Mahendran Date: Fri, 4 May 2018 14:25:19 +0800 Message-ID: Subject: Re: [PATCH 2/2] arm64/mm: add speculative page fault To: Laurent Dufour Cc: Catalin Marinas , Will Deacon , linux-arm-kernel@lists.infradead.org, linux-kernel , Linux-MM , Punit Agrawal 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 17:07 GMT+08:00 Laurent Dufour : > On 02/05/2018 09:54, Ganesh Mahendran wrote: >> 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. > > Thanks Ganesh, > > That's a great improvement, could you please provide details about the apps and > the hardware you used ? We run spf on Qcom SDM845(kernel 4.9). Below is app(popular in China) list we tested: ------ com.tencent.mobileqq com.tencent.qqmusic com.tencent.mtt com.UCMobile com.qiyi.video com.baidu.searchbox com.baidu.BaiduMap tv.danmaku.bili com.sdu.didi.psnger com.ss.android.ugc.aweme air.tv.douyu.android me.ele com.autonavi.minimap com.duowan.kiwi com.v.study com.qqgame.hlddz com.ss.android.article.lite com.jingdong.app.mall com.tencent.tmgp.pubgmhd com.kugou.android com.kuaikan.comic com.hunantv.imgo.activity com.mt.mtxx.mtxx com.sankuai.meituan com.sankuai.meituan.takeoutnew com.tencent.karaoke com.taobao.taobao com.tencent.qqlive com.tmall.wireless com.tencent.tmgp.sgame com.netease.cloudmusic com.sina.weibo com.tencent.mm com.immomo.momo com.xiaomi.hm.health com.youku.phone com.eg.android.AlipayGphone com.meituan.qcs.c.android ------ We will do more test of the V10 spf. > >> >> 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); >> + >> vma = find_vma(mm, addr); >> 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)) { > > As suggested by Punit in his v10's review, the test on > CONFIG_SPECULATIVE_PAGE_FAULT is not needed as handle_speculative_fault() is > defined to return VM_FAULT_RETRY is the config is not set. Thanks, 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. >> + */ > > The check of VM_FAULT_SIGSEGV was needed on ppc64 because of the memory > protection key support, but as far as I know, this is not the case on arm64. > Isn't it ? Yes, wil fix. > >> + if (fault != VM_FAULT_RETRY && >> + fault != VM_FAULT_SIGSEGV) { >> + perf_sw_event(PERF_COUNT_SW_SPF, 1, regs, addr); >> + goto done; >> + } >> + } else { >> + vma = NULL; >> + } >> + >> /* >> * 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; >> + >> goto retry; >> } >> } >> up_read(&mm->mmap_sem); >> >> +done: >> + >> /* >> * Handle the "normal" (no error) case first. >> */ >> >