[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <84144f020810310728j1f3b8a99se428ec55b0c165b5@mail.gmail.com>
Date: Fri, 31 Oct 2008 16:28:57 +0200
From: "Pekka Enberg" <penberg@...helsinki.fi>
To: "Evgeniy Polyakov" <s0mbre@...rvice.net.ru>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
"Peter Zijlstra" <a.p.zijlstra@...llo.nl>,
"Ingo Molnar" <mingo@...e.hu>,
"David Miller" <davem@...emloft.net>,
"Christoph Lameter" <cl@...ux-foundation.org>,
"Matthew Wilcox" <matthew@....cx>
Subject: SLAB vs. SLUB tbench regression (Was: [tbench regression fixes]: digging out smelly deadmen.)
Hi Evgeniy,
On Fri, Oct 10, 2008 at 1:17 AM, Evgeniy Polyakov
<s0mbre@...rvice.net.ru> wrote:
> It was reported recently that tbench has a long history of regressions,
> starting at least from 2.6.23 kernel. I verified that in my test
> environment tbench 'lost' more than 100 MB/s from 470 down to 355
> between at least 2.6.24 and 2.6.27. 2.6.26-2.6.27 performance regression
> in my machines is rougly corresponds to 375 down to 355 MB/s.
As you've already pointed out in private and in your blog, some part
of the tbench regression comes from SLUB vs. SLAB as well. Looks like
I can reproduce the regression locally as well:
[ 8 clients and tbench_srv on the same machine on 2-way x86-64 ]
min max avg sd
2.6.28-rc2-slab 234.57 244.88 242.68 0.71
2.6.28-rc2-slub 227.44 240.90 239.08 0.78
Oprofile seems to be busted for 2.6.28-rc2 so I'll follow up on this
as soon as that's settled.
Btw, just as one more data point, I accidentally tested with just 2
clients at first and SLUB actually beat SLAB.
Pekka
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists