Re: [patch 0/2] x86,pat: Reduce contention on the memtype_lock -V4

[Suresh Siddha <suresh.b.siddha@intel.com>]

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@sgi.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