[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20170710171536.GA5716@ram.oc3035372033.ibm.com>
Date: Mon, 10 Jul 2017 10:15:36 -0700
From: Ram Pai <linuxram@...ibm.com>
To: Anshuman Khandual <khandual@...ux.vnet.ibm.com>
Cc: linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
linux-arch@...r.kernel.org, linux-mm@...ck.org, x86@...nel.org,
linux-doc@...r.kernel.org, linux-kselftest@...r.kernel.org,
benh@...nel.crashing.org, paulus@...ba.org, mpe@...erman.id.au,
aneesh.kumar@...ux.vnet.ibm.com, bsingharora@...il.com,
dave.hansen@...el.com, hbabu@...ibm.com, arnd@...db.de,
akpm@...ux-foundation.org, corbet@....net, mingo@...hat.com
Subject: Re: [RFC v5 00/38] powerpc: Memory Protection Keys
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
Powered by blists - more mailing lists