On Fri, Dec 21, 2012 at 10:58:48PM -0500, Rik van Riel wrote: > On 12/21/2012 10:49 PM, Steven Rostedt wrote: > >On Fri, Dec 21, 2012 at 09:51:35PM -0500, Rik van Riel wrote: > > >>However, since spinlock contention should not be the > >>usual state, and all a scalable lock does is make sure > >>that N+1 CPUs does not perform worse than N CPUs, using > >>scalable locks is a stop-gap measure. > >> > >>I believe a stop-gap measure should be kept as simple as > >>we can. I am willing to consider moving to a per-lock > >>delay factor if we can figure out an easy way to do it, > >>but I would like to avoid too much extra complexity... > > > >Rik, > > > >I like your solution. It's rather simple and simple solutions tend to > >end up being the closest to optimal. The more complex a solution gets, > >the more it starts chasing fireflies. > > >Anyway, I'd like to see this code tested, and more benchmarks run > >against it. > > Absolutely. I would love to see if this code actually > causes regressions anywhere. > > It is simple enough that I suspect it will not, but there > really is only one way to find out. > > The more people test this with different workloads on > different SMP systems, the better. >
Great work Rik, I have a couple of small SMP systems I'll start to test with your patches, also I might be able to test this work after new year's eve on a big SMP box that seems to be facing a severe lock starvation issue due to the BUS saturation your work is aiming to reduce. Cheers! -- Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
