On Mon, 2008-09-08 at 12:13 -0400, jim owens wrote: > Chris Mason wrote: > >> My guess is that the improvement happens mostly from the first couple of tries, > >> not from repeated spinning. And since it is a mutex, you could even do: > > > > I started with lower spin counts, I really didn't want to spin at all > > but the current values came from trial and error. > > Exactly the problem Steven is saying about adaptive locking. > > Using benchmarks (or any test), on a small sample of systems > leads you to conclude "this design/tuning combination is better". > > I've been burned repeatedly by that... ugly things happen > as you move away from your design testing center. > > I'm not saying your code does not work, just that we need > a lot more proof with different configurations and loads > to see that is "at least no worse". Oh, I completely agree. This is tuned on just one CPU in a handful of workloads. In general, it makes sense to spin for about as long as it takes someone to do a btree search in the block, which we could benchmark up front at mount time. I could also get better results from an API where the holder of the lock indicates it is going to hold on to things for a while, which might happen right before doing an IO. Over the long term these are important issues, but for today I'm focused on the disk format ;) -chris -- 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
