Possible Threading problem with -CURRENT / MySQL?
Julian Elischer
julian at elischer.org
Wed Jun 16 07:49:08 GMT 2004
On Wed, 16 Jun 2004, Robert Watson wrote:
>
> On Wed, 16 Jun 2004, Robert Watson wrote:
>
> > On Wed, 16 Jun 2004, Robert Watson wrote:
> >
> > > Netperf-UP-giant 4902.41 14.3
> > > Netperf-SMP-giant 2566.18 16.83
> > > Netperf-UP-mpsafe 4799.35 22.04
> > > Netperf-SMP-mpsafe 3022.51 18.06
> >
> > FYI, when I add ADAPTIVE_MUTEXES on this box, the mean of 3000 q/s goes
> > to 4000 q/s on the netperf+smp+mpsafenet number.
> >
> > I'm off to bed now, but it seems like (at least in the HTT
> > configuration), it makes a big difference. I'll run the remainder of
> > that set with ADAPTIVE_MUTEXES tomorrow as well.
>
> And switching to 4BSD from ULE takes the mean to 6426 q/s when combined
> with netperf, smp, debug.mpsafenet=1, and adaptive mutexes.
>
> (Keeping in mind that this mysql benchmark is basically an
> inter-thread/process kernel IPC benchmark using UNIX domain sockets, since
> the workload is fairly minimal in userspace, this makes reasonable sense).
>
> Now I'm really going to bed.
One thing that was happenning at one time, was that when a process is
made runnable on
one processor, If another processor is idle, it remains idle until the
next scheduling tick.
I proposed patches about a year ago that fixed this but "as far as I
know" it is still true.
The solution is to generate an IPI when you make a thread runnable and
you see an idle processor..
To see if this is the problem a quick test would be to move HZ to 5000
or something and see what happens.
>
> Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
> robert at fledge.watson.org Senior Research Scientist, McAfee Research
>
>
>
More information about the freebsd-threads
mailing list