Re: HyperThreading

看板DFBSD_kernel作者saman.時間15年前 (2011/02/19 02:32)推噓0(0推 0噓 0→)

留言0則, 0人參與討論串10/16 (看更多)

--90e6ba6e8a2e3f9909049c924a82 Content-Type: text/plain; charset=ISO-8859-1 It would be great if you had the SMP results as well. Anyway, I think you would love this: http://www.cs.uwaterloo.ca/~sbarghi/bench/transactions1.jpg

(keep in mind that this is a quad core xenon with 2 GB of RAM, and FreeBSD is in SMP mode) As I said before; I kept the environment the the same as what has been mentioned here: http://people.freebsd.org/~kris/scaling/dfly.html . I even used the same version of MySQL (5.0) although MySQL 5.5 shows better scaling behaviour.( http://mikaelronstrom.blogspot.com/2010/04/mysql-554-m3-scales-to-32-cores.html). IMHO if "The multiprocessor work that has been ongoing in DragonFly is really starting to bear fruit", the fruits are indeed juicy and sweet. It would be lovely to see the results on a machine with more cores though. Btw, is there any changelog that shows what has been changed about tokens !? Cheers, Saman On Fri, Feb 18, 2011 at 11:00 AM, Venkatesh Srinivas <me@endeavour.zapto.org > wrote: > Sysbench OLTP is a very solid test; I'd love to see any results you get > from it, either with Postgres or MySQL as a database server. > > http://m-net.arbornet.org/~sv5679/sysbench_nmalloc_df.gif

are results from > the spring of last year, very early in the 2.7 branch, for Sysbench/OLTP > with MySQL against Dfly. Despite the title of the graph, this was on an > 8-core Xeon (Nehalem-based) system; also not shown on the graph are the UP > kernel results -- the UP kernel with the old libc malloc had a more or less > flat line at 650 transactions/sec (which was distressingly always faster > than the SMP kernel!) and the UP kernel with the new libc malloc had a flat > line at around 800 transactions/sec. With Google's tcmalloc, we had much > better results, but I don't have those numbers handy. > > We've really broken up the MP lock since then; the LWKT scheduler has been > changed a lot (round-robin -> fair share); tokens have been reworked twice; > and even the 4BSD scheduler has had work. I'd love to see if we're merely > rearranging deck chairs or if we've actually improved matters... > > -- vs > > --90e6ba6e8a2e3f9909049c924a82 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">It would be great if you had the SMP results as well. Anyw= ay, I think you would love this: =A0<a href=3D"http://www.cs.uwaterloo.c= a/~sbarghi/bench/transactions1.jpg">http://www.cs.uwaterloo.ca/~sbarghi/ben= ch/transactions1.jpg</a> (keep in mind that this is a quad core xenon with 2 GB of RAM, and FreeBSD = is in SMP mode) As I said before; I kept the environment the the sam= e as what has been mentioned here: <a href=3D"http://people.freebsd.org/~kr= is/scaling/dfly.html">http://people.freebsd.org/~kris/scaling/dfly.html</a>= . I even used the same version of MySQL (5.0) although MySQL=A0 5.5 shows = better scaling behaviour.(<a href=3D"http://mikaelronstrom.blogspot.com/201= 0/04/mysql-554-m3-scales-to-32-cores.html">http://mikaelronstrom.blogspot.c= om/2010/04/mysql-554-m3-scales-to-32-cores.html</a>). IMHO if "The mul= tiprocessor work that has been ongoing in DragonFly is really starting to b= ear fruit", the fruits are indeed juicy and sweet.=A0 It would be love= ly to see the results on a machine with more cores though. Btw, is there any changelog that shows what has been changed about toke= ns !? Cheers, Saman <div class=3D"gmail_quote">On Fri= , Feb 18, 2011 at 11:00 AM, Venkatesh Srinivas <<a hre= f=3D"mailto:me@endeavour.zapto.org">me@endeavour.zapto.org</a>> w= rote: <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Sysbench OLTP is = a very solid test; I'd love to see any results you get from it, either = with Postgres or MySQL as a database server. <a href=3D"http://m-net.arbornet.org/%7Esv5679/sysbench_nmalloc_df.gif"= target=3D"_blank">http://m-net.arbornet.org/~sv5679/sysbench_nmalloc_df.gi= f</a> are results from the spring of last year, very early in the 2.7 branc= h, for Sysbench/OLTP with MySQL against Dfly. Despite the title of the grap= h, this was on an 8-core Xeon (Nehalem-based) system; also not shown on the= graph are the UP kernel results -- the UP kernel with the old libc malloc = had a more or less flat line at 650 transactions/sec (which was distressing= ly always faster than the SMP kernel!) and the UP kernel with the new libc = malloc had a flat line at around 800 transactions/sec. With Google's tc= malloc, we had much better results, but I don't have those numbers hand= y. We've really broken up the MP lock since then; the LWKT scheduler h= as been changed a lot (round-robin -> fair share); tokens have been rewo= rked twice; and even the 4BSD scheduler has had work. I'd love to see i= f we're merely rearranging deck chairs or if we've actually improve= d matters... -- vs </blockquote></div> </div> --90e6ba6e8a2e3f9909049c924a82--

‣ 返回看板[ DFBSD_kernel ] DBSD

‣ 更多 saman. 的文章

文章代碼(AID): #1DNhic-W (DFBSD_kernel)