linux-kernel - Re: SMP performance degradation with sysbench

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <29495f1d0702281620j43f576ack2d7e942136e8ea56@mail.gmail.com>
Date:	Wed, 28 Feb 2007 16:20:54 -0800
From:	"Nish Aravamudan" <nish.aravamudan@...il.com>
To:	"Bill Davidsen" <davidsen@....com>
Cc:	"Paulo Marques" <pmarques@...popie.com>,
	"Rik van Riel" <riel@...hat.com>,
	"J.A. Magallón" <jamagallon@....com>,
	"Hiro Yoshioka" <hyoshiok@...aclelinux.com>, davej@...hat.com,
	harlan@...select.com, nickpiggin@...oo.com.au,
	l_allegrucci@...oo.it, linux-kernel@...r.kernel.org, mingo@...e.hu,
	suparna@...ibm.com, jens.axboe@...cle.com
Subject: Re: SMP performance degradation with sysbench

On 2/27/07, Nish Aravamudan <nish.aravamudan@...il.com> wrote:
> On 2/27/07, Bill Davidsen <davidsen@....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.
<snip>
> > > If that is the case, turning off CONFIG_SCHED_SMT would solve the problem.
<snip>
> > 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.

Here are the results:

idle.png: average % idle over 120s runs from 1 to 32 threads
transactions.png: TPS over 120s runs from 1 to 32 threads

Hope the data is useful. All I can conclude right now is that SMT
appears to help (contradicting what I said earlier), but that MC seems
to have no effect (or no substantial effect).

Thanks,
Nish

Download attachment "idle.png" of type "image/png" (5482 bytes)

Download attachment "transactions.png" of type "image/png" (6653 bytes)