recent -CURRENT changes were very bad for MySQL...

[JG]

At 01:54 AM 6/16/2004 -0700, you wrote:
>On Mon, Jun 14, 2004 at 06:34:28PM -0700, JG wrote:
> > amd64f# super-smack update-select.smack 30 10000
> >
> > Query Barrel Report for client smacker
> > connect: max=46ms  min=2ms avg= 26ms from 30 clients
> > Query_type      num_queries     max_time        min_time        q_per_s
> > select_index    300000  2       0       958.05
> > update_index    300000  2       0       958.05
> >
> > In all my previous tests I think that number was at least 2000/qps
> > (and that was bad) and as much as 4000/qps.
> >
> > Whatever was changed recently really killed performance in this area.
> >
> > This is a SMP kerenel using SCHED_ULE.
>
>Try commenting out the "options ADAPTIVE_MUTEXES" in GENERIC, and let
>this list know if you see any different..

It stopped the erratic numbers and went back to the usual predictably 
depressing ones when
I commented out ADAPTIVE_MUTEXES and ran SCHED_4BSD instead of _ULE

(a kernel without ADAPTIVE_MUTEXES w/_ULE failed make ~ some PCI audio 
stuff, strange, since it didn't fail there before)

Anyway Robert Watson (far more qualified at this than me) has been running 
some MySQL
benchmarks and publishing the results in FreeBSD-threads. It's starting to 
look promising,
but in all of his benchmarks that have decent numbers, he specifically has 
enabled ADAPTIVE_MUTEXES...
so maybe this is a problem with ADAPTIVE_MUTEXES that applies specifically 
to the AMD64 branch?

- Jeremy