Messages in this thread | | | Date | Tue, 27 Feb 2007 12:40:45 -0800 | From | "Nish Aravamudan" <> | Subject | Re: SMP performance degradation with sysbench |
| |
On 2/27/07, Paulo Marques <pmarques@grupopie.com> wrote: > Rik van Riel wrote: > > J.A. Magallón wrote: > >>[...] > >> Its the same to answer 4+4 queries than 8 at half the speed, isn't it ? > > > > That still doesn't fix the potential Linux problem that this > > benchmark identified. > > > > To clarify: I don't care as much about MySQL performance as > > I care about identifying and fixing this potential bug in > > Linux. > > IIRC a long time ago there was a change in the scheduler to prevent a > low prio task running on a sibling of a hyperthreaded processor to slow > down a higher prio task on another sibling of the same processor. > > Basically the scheduler would put the low prio task to sleep during an > adequate task slice to allow the other sibling to run at full speed for > a while. > > I don't know the scheduler code well enough, but comments like this one > make me think that the change is still in place:
<snip>
> If that is the case, turning off CONFIG_SCHED_SMT would solve the problem.
To chime in here, I was attempting to reproduce this on an 8-way Xeon box (4 dual-core). SCHED_SMT and SCHED_MC on led to scaling issues when above 4 threads (4 threads was the peak). To the point, where I couldn't break 1000 transactions per second. Turning both off (with 2.6.20.1) gives much better performance through 16 threads. I am now running for the cases from 17 to 32 to see if I can reproduce the problem at hand. I'll regenerate my data and post numbers soon.
I don't know if anyone else has those on in their kernel .config, but I'd suggest turning them off, as Paulo said.
Thanks, Nish - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |