Date: Thu, 17 Jun 2004 07:42:02 -0700 From: JG <amd64list@jpgsworld.com> To: freebsd-amd64@freebsd.org Subject: Re: recent -CURRENT changes were very bad for MySQL... Message-ID: <5.2.0.9.2.20040617073807.033261a0@mail.ojoink.com> In-Reply-To: <5.2.0.9.2.20040617070109.03265740@mail.ojoink.com> References: <20040616085435.GA46538@dragon.nuxi.com> <5.2.0.9.2.20040614175419.0162dd00@127.0.0.1> <5.2.0.9.2.20040614175419.0162dd00@127.0.0.1>
next in thread | previous in thread | raw e-mail | index | archive | help
>> >>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? Scratch that. I just compiled a kernel without AM and WITH _ULE (commenting out pcm so it would compile) and the erratic erratic performance locks came back. This means these erratic performance locks are due to the ULE scheduler and something that was recently changed in -CURRENT that would have to do with ULE. - Jeremy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5.2.0.9.2.20040617073807.033261a0>