Messages in this thread | | | From | "Rafael J. Wysocki" <> | Subject | Re: [patch 0/2] x86,pat: Reduce contention on the memtype_lock -V4 | Date | Wed, 24 Mar 2010 21:32:11 +0100 |
| |
On Wednesday 24 March 2010, Suresh Siddha wrote: > 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.
In fact Takashi did that, to put the record straight. :-)
Thanks, Rafael
| |