On Monday 08 September 2008 16:28:34 Chris Mason wrote: > > People seem to repeatedly come up with adaptive mutex based on intuitive > > hunch, and never do much analysis before or afterwards. > > In my case, it very easy to measure. Just watch the context switch rate > on any metadata intensive workload. The current code scores higher on > benchmarks and uses less system time overall. > Given that it's system-dependent, perhaps making the 512 a #define'd value (defaulting to 512) while it's current, might be worth doing? That would allow users to test via different values passed to make, and so gather more data, or just use the setting they prefer, if they're bothered. At least until the adaptive mutex API is worked out (which might well take the number of attempts to spin/relax as a parameter. I'd add a shouldYield [for before final acquisition] and keep the ifSleeping as implicit in another fn, based on what I've read, but thankfully that's not my problem.) -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
