Received: by 10.223.164.221 with SMTP id h29csp472343wrb; Thu, 26 Oct 2017 01:17:14 -0700 (PDT) X-Google-Smtp-Source: ABhQp+RnxRUJd16nQKTTnpbJCFfaz9g8SwRptAkCvNK82+HOaqqbk1Fvhsvjz+VmGSKZTYdOy7bh X-Received: by 10.98.110.73 with SMTP id j70mr4544625pfc.146.1509005834105; Thu, 26 Oct 2017 01:17:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1509005834; cv=none; d=google.com; s=arc-20160816; b=hCft8hm5n6Pb70GU5y7huaFrLKev/3ZHKF8SfR/6l3kcnboOWnb5T/gx9MKNecdmGQ CpTxKaAWDQ+wh4++7Sqi3kaUYWV10kSCChnEYHuD5Le9MijLYT/XUCOZuFW5aibnrGi+ bLwyh4UWhzb6D9/0i/G3Q7JZYS4nInhdrqpC2vQZqJN3FgYyOWEWbQGozsagRmpOyq6T X0U4Er2yScc9nxoW++IZY7S0oP5GsAhcpC4FdzOrATvuccp0hbj9JShprfxfvGW1u3kD CqDRqEyn1iJq8u+r6OMpLdCjg6rJNJEgngeOeWXqTpkyacP+RxTEehDYeBKt3K1iQpT9 F/AA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=4dAIM2QTpoKsYqee8nXOcDWlLkLrAUvzGgz2SCqYyIc=; b=OzlZYFXYb9An9eNf8rFlJLQdVlZ1IyJt/eKl4Uu/nMsu8zWIKWIT7TBZYZ+1eIiT7Z WFfpOtVwCpzZ6PFdE30J3A/c+Bjh7EaGsTr4BqKc4vsHR/4THo86xpGP27Du7tIBqg36 C5to9Pw85zNsqZhzVuCtRGrCa3uYFO27tnWzSV06XSao6G9D+wlV4HW1BZNa81IaxvdZ CglQHrFb7QRotUa/G5teRlxqez/FnV+bPMKYA1ed0a5egUL67/4LZhjeCkJpww3pRqJ6 d9NErFtAUp6ieKhwvXgitDgDgCEVfgADl97uLnq4OecVPqOb5M2nJkTavDB7Bcn3iSrB QC7A== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d37si2682848plb.276.2017.10.26.01.17.00; Thu, 26 Oct 2017 01:17:14 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752052AbdJZIQP (ORCPT + 99 others); Thu, 26 Oct 2017 04:16:15 -0400 Received: from mga14.intel.com ([192.55.52.115]:12476 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751483AbdJZIQK (ORCPT ); Thu, 26 Oct 2017 04:16:10 -0400 Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Oct 2017 01:16:09 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.43,434,1503385200"; d="scan'208";a="142409087" Received: from kemi-desktop.sh.intel.com (HELO [10.239.13.3]) ([10.239.13.3]) by orsmga004.jf.intel.com with ESMTP; 26 Oct 2017 01:16:04 -0700 Subject: Re: [v5,22/22] powerpc/mm: Add speculative page fault To: Laurent Dufour , 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 Cc: 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 References: <1507729966-10660-23-git-send-email-ldufour@linux.vnet.ibm.com> From: kemi Message-ID: <7ca80231-fe02-a3a7-84bc-ce81690ea051@intel.com> Date: Thu, 26 Oct 2017 16:14:21 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1507729966-10660-23-git-send-email-ldufour@linux.vnet.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Some regression is found by LKP-tools(linux kernel performance) on this patch series tested on Intel 2s/4s Skylake platform. The regression result is sorted by the metric will-it-scale.per_process_ops. Branch:Laurent-Dufour/Speculative-page-faults/20171011-213456(V4 patch series) Commit id: base:9a4b4dd1d8700dd5771f11dd2c048e4363efb493 head:56a4a8962fb32555a42eefdc9a19eeedd3e8c2e6 Benchmark suite:will-it-scale Download link:https://github.com/antonblanchard/will-it-scale/tree/master/tests Metrics: will-it-scale.per_process_ops=processes/nr_cpu will-it-scale.per_thread_ops=threads/nr_cpu tbox:lkp-skl-4sp1(nr_cpu=192,memory=768G) kconfig:CONFIG_TRANSPARENT_HUGEPAGE is not set testcase base change head metric brk1 2251803 -18.1% 1843535 will-it-scale.per_process_ops 341101 -17.5% 281284 will-it-scale.per_thread_ops malloc1 48833 -9.2% 44343 will-it-scale.per_process_ops 31555 +2.9% 32473 will-it-scale.per_thread_ops page_fault3 913019 -8.5% 835203 will-it-scale.per_process_ops 233978 -18.1% 191593 will-it-scale.per_thread_ops mmap2 95892 -6.6% 89536 will-it-scale.per_process_ops 90180 -13.7% 77803 will-it-scale.per_thread_ops mmap1 109586 -4.7% 104414 will-it-scale.per_process_ops 104477 -12.4% 91484 will-it-scale.per_thread_ops sched_yield 4964649 -2.1% 4859927 will-it-scale.per_process_ops 4946759 -1.7% 4864924 will-it-scale.per_thread_ops write1 1345159 -1.3% 1327719 will-it-scale.per_process_ops 1228754 -2.2% 1201915 will-it-scale.per_thread_ops page_fault2 202519 -1.0% 200545 will-it-scale.per_process_ops 96573 -10.4% 86526 will-it-scale.per_thread_ops page_fault1 225608 -0.9% 223585 will-it-scale.per_process_ops 105945 +14.4% 121199 will-it-scale.per_thread_ops tbox:lkp-skl-4sp1(nr_cpu=192,memory=768G) kconfig:CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y testcase base change head metric context_switch1 333780 -23.0% 256927 will-it-scale.per_process_ops brk1 2263539 -18.8% 1837462 will-it-scale.per_process_ops 325854 -15.7% 274752 will-it-scale.per_thread_ops malloc1 48746 -13.5% 42148 will-it-scale.per_process_ops mmap1 106860 -12.4% 93634 will-it-scale.per_process_ops 98082 -18.9% 79506 will-it-scale.per_thread_ops mmap2 92468 -11.3% 82059 will-it-scale.per_process_ops 80468 -8.9% 73343 will-it-scale.per_thread_ops page_fault3 900709 -9.1% 818851 will-it-scale.per_process_ops 229837 -18.3% 187769 will-it-scale.per_thread_ops write1 1327409 -1.7% 1305048 will-it-scale.per_process_ops 1215658 -1.6% 1196479 will-it-scale.per_thread_ops writeseek3 300639 -1.6% 295882 will-it-scale.per_process_ops 231118 -2.2% 225929 will-it-scale.per_thread_ops signal1 122011 -1.5% 120155 will-it-scale.per_process_ops futex1 5123778 -1.2% 5062087 will-it-scale.per_process_ops page_fault2 202321 -1.0% 200289 will-it-scale.per_process_ops 93073 -9.8% 83927 will-it-scale.per_thread_ops tbox:lkp-skl-2sp2(nr_cpu=112,memory=64G) kconfig:CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y testcase base change head metric brk1 2177903 -20.0% 1742054 will-it-scale.per_process_ops 434558 -15.3% 367896 will-it-scale.per_thread_ops malloc1 64871 -10.3% 58174 will-it-scale.per_process_ops page_fault3 882435 -9.0% 802892 will-it-scale.per_process_ops 299176 -15.7% 252170 will-it-scale.per_thread_ops mmap2 124567 -8.3% 114214 will-it-scale.per_process_ops 110674 -12.1% 97272 will-it-scale.per_thread_ops mmap1 137205 -7.8% 126440 will-it-scale.per_process_ops 128973 -15.1% 109560 will-it-scale.per_thread_ops context_switch1 343790 -7.2% 319209 will-it-scale.per_process_ops page_fault2 161891 -2.1% 158458 will-it-scale.per_process_ops 123278 -5.4% 116629 will-it-scale.per_thread_ops malloc2 14354856 -1.8% 14096856 will-it-scale.per_process_ops read2 1204838 -1.7% 1183993 will-it-scale.per_process_ops futex1 5017718 -1.6% 4938677 will-it-scale.per_process_ops 1408250 -1.0% 1394022 will-it-scale.per_thread_ops writeseek3 399651 -1.4% 393935 will-it-scale.per_process_ops signal1 157952 -1.0% 156302 will-it-scale.per_process_ops On 2017年10月11日 21:52, Laurent Dufour wrote: > This patch enable the speculative page fault on the PowerPC > architecture. > > This will try a speculative page fault without holding the mmap_sem, > if it returns with VM_FAULT_RETRY, the mmap_sem is acquired and the > traditional page fault processing is done. > > Build on if CONFIG_SPF is defined (currently for BOOK3S_64 && SMP). > > Signed-off-by: Laurent Dufour > --- > arch/powerpc/mm/fault.c | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) > > diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c > index 4797d08581ce..c018c2554cc8 100644 > --- a/arch/powerpc/mm/fault.c > +++ b/arch/powerpc/mm/fault.c > @@ -442,6 +442,20 @@ static int __do_page_fault(struct pt_regs *regs, unsigned long address, > if (is_exec) > flags |= FAULT_FLAG_INSTRUCTION; > > +#ifdef CONFIG_SPF > + if (is_user) { > + /* let's try a speculative page fault without grabbing the > + * mmap_sem. > + */ > + fault = handle_speculative_fault(mm, address, flags); > + if (!(fault & VM_FAULT_RETRY)) { > + perf_sw_event(PERF_COUNT_SW_SPF, 1, > + regs, address); > + goto done; > + } > + } > +#endif /* CONFIG_SPF */ > + > /* 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 > @@ -526,6 +540,9 @@ static int __do_page_fault(struct pt_regs *regs, unsigned long address, > > up_read(¤t->mm->mmap_sem); > > +#ifdef CONFIG_SPF > +done: > +#endif > if (unlikely(fault & VM_FAULT_ERROR)) > return mm_fault_error(regs, address, fault); > > From 1580969599939798795@xxx Wed Oct 11 13:55:02 +0000 2017 X-GM-THRID: 1580969599939798795 X-Gmail-Labels: Inbox,Category Forums