From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3yQXpL1CZqzDqmt for ; Mon, 30 Oct 2017 22:49:42 +1100 (AEDT) Received: from pps.filterd (m0098413.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9UBj8Hp097751 for ; Mon, 30 Oct 2017 07:49:39 -0400 Received: from e06smtp13.uk.ibm.com (e06smtp13.uk.ibm.com [195.75.94.109]) by mx0b-001b2d01.pphosted.com with ESMTP id 2dx0vsredd-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 30 Oct 2017 07:49:39 -0400 Received: from localhost by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 30 Oct 2017 11:49:38 -0000 From: "Aneesh Kumar K.V" To: Paul Mackerras Cc: benh@kernel.crashing.org, mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH 00/16] Remove hash page table slot tracking from linux PTE In-Reply-To: <20171027054136.GC27483@fergus.ozlabs.ibm.com> References: <20171027040833.3644-1-aneesh.kumar@linux.vnet.ibm.com> <20171027043430.GA27483@fergus.ozlabs.ibm.com> <20171027054136.GC27483@fergus.ozlabs.ibm.com> Date: Mon, 30 Oct 2017 17:19:31 +0530 MIME-Version: 1.0 Content-Type: text/plain Message-Id: <87tvyg26us.fsf@linux.vnet.ibm.com> List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Paul Mackerras writes: > On Fri, Oct 27, 2017 at 10:57:13AM +0530, Aneesh Kumar K.V wrote: >> >> >> On 10/27/2017 10:04 AM, Paul Mackerras wrote: >> >How do we interpret these numbers? Are they times, or speed? Is >> >larger better or worse? >> >> Sorry for not including the details. They are time in seconds. Test case is >> a modified mmap_bench included in powerpc/selftest. >> >> > >> >Can you give us the mean and standard deviation for each set of 5 >> >please? >> > >> >> powernv without patch >> median= 51.432255 >> stdev = 0.370835 >> >> with patch >> median = 50.739922 >> stdev = 0.06419662 >> >> pseries without patch >> median = 116.617884 >> stdev = 3.04531023 >> >> with patch no hcall >> median = 119.42494 >> stdev = 0.85874552 >> >> with patch and hcall >> median = 117.735808 >> stdev = 2.7624151 > > So on powernv, the patch set *improves* performance by about 1.3% > (almost 2 standard deviations). Do we know why that is? > I looked at the perf data and with the test, we are doing larger number of hash faults and then around 10k flush_hash_range. Can the small improvement in number be due to the fact that we are not storing slot number when doing an insert now?. Also in the flush path we are now not using real_pte_t. aneesh