On Fri, Mar 31, 2017 at 09:02:42AM -0700, Andi Kleen wrote: > On Fri, Mar 31, 2017 at 04:45:46PM +0200, Peter Zijlstra wrote: > > On Fri, Mar 31, 2017 at 06:54:48AM -0700, Andi Kleen wrote: > > > > Argh! > > > > > > > > Andrew, please drop that patch. And the x86 out-of-line of __atomic_add_unless(). > > > > > > Why dropping the second? Do you have something better? > > > > The try_cmpxchg() patches save about half the text, and do not have the > > out-of-line penalty as shown here: > > > > https://lkml.kernel.org/r/20170322165144.dtidvvbxey7w5pbd@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > > Where is the source for the benchmark? In that email; heck marc.info even provides a downloadable link, you don't even have to go find it in your local lkml archives. > Based on the description it sounds like it's testing atomic_inc(), > which my patches don't change. Yes, reading is hard. It tests: lock incl vs call refcount_inc vs $inlined refcount_inc And refcount_inc() is more complex than add_unless(). > BTW testing such things in tight loops is bad practice. If you run > them back to back the CPU pipeline has to do much more serialization, > which is usually not realistic and drastically overestimates > the overhead. > > A better practice is to run some real workload. If you want to see > cycle counts you can look at LBR cycles, or PT cycles from sampling or tracing. Hey, at least I did benchmark it. You just waved your hands and are causing extra work for other people. > > > On the first there were no 0day regressions, so at least basic performance > > > checking has been done. > > > > The first is superseded by much better patches in the scheduler tree. > > Which patches exactly? The new patches shrink the text too? Try your local google foo; or look at the patch that conflicted, its that one and the next. In the end it comes down to -mm carrying patches against trees that are maintained elsewhere without acks from said maintainers. I don't feel bad about causing conflicts. -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
