On Tue, Nov 23, 2010 at 06:49:47PM +0200, Antti Kantee wrote: > On Fri Nov 19 2010 at 00:11:12 +0000, Andrew Doran wrote: > > You can release it with either call, mutex_spin_ is just a way to avoid > > additional atomic operations. The ususal case is adaptive mutex, but > > stuff like the dispatcher/scheduler makes use of spin mutexes exclusively > > and the fast path versions were invented for that. (Because you can measure > > the effect with benchmarks :-). > > Speaking of which, something I (and a few others) have been thinking > about is to have constantly running benchmarks (akin to constantly > running tests). That way we can have a rough idea which way performance > and resource consumption is going and if there are any sharp regressions. > Are your old benchmarking programs still available somewhere?
I think this is a great idea. Here are the easy ones: - libmicro. I had adjustments to this to use -O0 and something to do with the timekeeping, I can't remember exactly. - hackbench - build.sh on a static, unchanging source tree. - mysql sysbench. I had lots of one-offs and more complicated setups but the above are really easy to set up and repeat.
