linux-kernel - Re: [patch 0/2] x86,pat: Reduce contention on the memtype

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 24 Mar 2010 09:22:17 -0700
From:	Suresh Siddha <suresh.b.siddha@...el.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Robin Holt <holt@....com>, Andi Kleen <andi@...stfloor.org>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Venkatesh Pallipadi <venkatesh.pallipadi@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"x86@...nel.org" <x86@...nel.org>, Rafael Wysocki <rjw@...ell.com>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [patch 0/2] x86,pat: Reduce contention on the memtype_lock -V4

On Wed, 2010-03-24 at 04:15 -0700, Thomas Gleixner wrote:
> On Wed, 24 Mar 2010, Robin Holt wrote:
> > On Wed, Mar 24, 2010 at 03:16:14AM +0100, Andi Kleen wrote:
> > > holt@....com writes:
> > > 
> > > > Tracking memtype on x86 uses a single global spin_lock for either reading
> > > > or changing the memory type.  This includes changes made to page flags
> > > > which is perfectly parallel.
> > > >
> > > > Part one of the patchset makes the page-based tracking use cmpxchg
> > > > without a need for a lock.
> > > >
> > > > Part two of the patchset converts the spin_lock into a read/write lock.
> > > 
> > > I'm curious: in what workloads did you see contention?
> > > 
> > > For any scalability patches it would be always good to have a description
> > > of the workload.
> > 
> > It was a job using xpmem (an out of tree kernel module) which uses
> > vm_insert_pfn to establish ptes.  The scalability issues were shown
> > in the first patch.  I do not have any test which shows a performance
> > difference  with the spin_lock to rw_lock conversion.
> 
> And what's exactly the point of converting it to a rw_lock then ?

Thomas, As I mentioned earlier I am ok in not doing this conversion. If
we see any performance issues with this spinlock, we can use RCU based
logic to address that.

For now, first patch in this series (which avoid the lock for RAM pages)
is good to go. Thanks Rafael for spotting the page flags bit
manipulation issue.

thanks,
suresh

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/