From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932720AbdGJRP6 (ORCPT ); Mon, 10 Jul 2017 13:15:58 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:43285 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932067AbdGJRPy (ORCPT ); Mon, 10 Jul 2017 13:15:54 -0400 Date: Mon, 10 Jul 2017 10:15:36 -0700 From: Ram Pai To: Anshuman Khandual Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au, aneesh.kumar@linux.vnet.ibm.com, bsingharora@gmail.com, dave.hansen@intel.com, hbabu@us.ibm.com, arnd@arndb.de, akpm@linux-foundation.org, corbet@lwn.net, mingo@redhat.com Subject: Re: [RFC v5 00/38] powerpc: Memory Protection Keys Reply-To: Ram Pai References: <1499289735-14220-1-git-send-email-linuxram@us.ibm.com> <20170710060544.GF5713@ram.oc3035372033.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170710060544.GF5713@ram.oc3035372033.ibm.com> User-Agent: Mutt/1.5.20 (2009-12-10) X-TM-AS-GCONF: 00 x-cbid: 17071017-8235-0000-0000-00000BE5B967 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007344; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000214; SDB=6.00885625; UDB=6.00441993; IPR=6.00665774; BA=6.00005464; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00016160; XFM=3.00000015; UTC=2017-07-10 17:15:52 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17071017-8236-0000-0000-00003CAE7F5A Message-Id: <20170710171536.GA5716@ram.oc3035372033.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-07-10_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707100303 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jul 09, 2017 at 11:05:44PM -0700, Ram Pai wrote: > On Mon, Jul 10, 2017 at 11:13:23AM +0530, Anshuman Khandual wrote: > > On 07/06/2017 02:51 AM, Ram Pai wrote: ..... > > > do you have data points to show the difference in > > performance between this version and the last one where > > we skipped the bits from PTE and directly programmed the > > HPTE entries looking into VMA bits. > > No. I dont. I am hoping you can help me out with this. Anshuman, The last version where we skipped the PTE bits is guaranteed to be bad/horrible. For one it has a bug, since it accesses the vma without a lock. And even if we did take a lock, it will slow down the page-hash path un-acceptably. So there is no point measuring the performance of that design. I think the number we want to measure is -- the performance with the current design and comparing that to the performance without memkey feature. We want to find if there is any degradation by adding this feature. RP From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ram Pai Subject: Re: [RFC v5 00/38] powerpc: Memory Protection Keys Date: Mon, 10 Jul 2017 10:15:36 -0700 Message-ID: <20170710171536.GA5716@ram.oc3035372033.ibm.com> References: <1499289735-14220-1-git-send-email-linuxram@us.ibm.com> <20170710060544.GF5713@ram.oc3035372033.ibm.com> Reply-To: Ram Pai Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20170710060544.GF5713@ram.oc3035372033.ibm.com> Sender: owner-linux-mm@kvack.org To: Anshuman Khandual Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au, aneesh.kumar@linux.vnet.ibm.com, bsingharora@gmail.com, dave.hansen@intel.com, hbabu@us.ibm.com, arnd@arndb.de, akpm@linux-foundation.org, corbet@lwn.net, mingo@redhat.com List-Id: linux-arch.vger.kernel.org On Sun, Jul 09, 2017 at 11:05:44PM -0700, Ram Pai wrote: > On Mon, Jul 10, 2017 at 11:13:23AM +0530, Anshuman Khandual wrote: > > On 07/06/2017 02:51 AM, Ram Pai wrote: ..... > > > do you have data points to show the difference in > > performance between this version and the last one where > > we skipped the bits from PTE and directly programmed the > > HPTE entries looking into VMA bits. > > No. I dont. I am hoping you can help me out with this. Anshuman, The last version where we skipped the PTE bits is guaranteed to be bad/horrible. For one it has a bug, since it accesses the vma without a lock. And even if we did take a lock, it will slow down the page-hash path un-acceptably. So there is no point measuring the performance of that design. I think the number we want to measure is -- the performance with the current design and comparing that to the performance without memkey feature. We want to find if there is any degradation by adding this feature. RP -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org