Messages in this thread | | | Date | Tue, 27 Feb 2007 18:52:30 -0800 | From | "Nish Aravamudan" <> | Subject | Re: SMP performance degradation with sysbench |
| |
On 2/27/07, Bill Davidsen <davidsen@tmr.com> wrote: > Paulo Marques 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: > > > >> /* > >> * If an SMT sibling task has been put to sleep for priority > >> * reasons reschedule the idle task to see if it can now run. > >> */ > >> if (rq->nr_running) { > >> resched_task(rq->idle); > >> ret = 1; > >> } > > > > If that is the case, turning off CONFIG_SCHED_SMT would solve the problem. > > > That may be the case, but in my opinion if this helps it doesn't "solve" > the problem, because the real problem is that a process which is not on > a HT is being treated as if it were. > > Note that Intel does make multicore HT processors, and hopefully when > this code works as intended it will result in more total throughput. My > supposition is that it currently is NOT working as intended, since > disabling SMT scheduling is reported to help.
It does help, but we still drop off, clearly. Also, that's my baseline, so I'm not able to reproduce the *sharp* dropoff from the blog post yet.
> A test with MC on and SMT off would be informative for where to look next.
I'm rebooting my box with 2.6.20.1 and exactly this setup now.
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/
| |