[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <29495f1d0703131736l74a63c15n94f03527d7e63500@mail.gmail.com>
Date: Tue, 13 Mar 2007 17:36:36 -0700
From: "Nish Aravamudan" <nish.aravamudan@...il.com>
To: "Anton Blanchard" <anton@...ba.org>
Cc: "Nick Piggin" <nickpiggin@...oo.com.au>,
"Rik van Riel" <riel@...hat.com>,
"Lorenzo Allegrucci" <l_allegrucci@...oo.it>,
linux-kernel@...r.kernel.org, "Ingo Molnar" <mingo@...e.hu>,
"Suparna Bhattacharya" <suparna@...ibm.com>,
"Jens Axboe" <jens.axboe@...cle.com>
Subject: Re: SMP performance degradation with sysbench
On 3/12/07, Anton Blanchard <anton@...ba.org> wrote:
>
> Hi Nick,
>
> > Anyway, I'll keep experimenting. If anyone from MySQL wants to help look
> > at this, send me a mail (eg. especially with the sched_setscheduler issue,
> > you might be able to do something better).
>
> I took a look at this today and figured Id document it:
>
> http://ozlabs.org/~anton/linux/sysbench/
>
> Bottom line: it looks like issues in the glibc malloc library, replacing
> it with the google malloc library fixes the negative scaling:
>
> # apt-get install libgoogle-perftools0
> # LD_PRELOAD=/usr/lib/libtcmalloc.so /usr/sbin/mysqld
Quick datapoint, still collecting data and trying to verify it's
always the case: on my 8-way Xeon, I'm actually seeing *much* worse
performance with libtcmalloc.so compared to mainline. Am generating
graphs and such still, but maybe someone else with x86_64 hardware
could try the google PRELOAD and see if it helps/hurts (to rule out
tester stupidity)?
Thanks,
Nish
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists