From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
"David S. Miller" <davem@davemloft.net>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Eric Dumazet <edumazet@google.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Gao feng <gaofeng@cn.fujitsu.com>
Subject: Re: Hack bench regression with CONFIG_SLUB_CPU_PARTIAL disabled (info only)
Date: Thu, 25 Jul 2013 18:50:58 +0530 [thread overview]
Message-ID: <51F1263A.6070704@linux.vnet.ibm.com> (raw)
In-Reply-To: <1374750359.23313.17.camel@edumazet-glaptop>
On 07/25/2013 04:35 PM, Eric Dumazet wrote:
> On Thu, 2013-07-25 at 13:30 +0530, Raghavendra K T wrote:
>> Hi,
>>
>> While testing hackbench with 3.11-rc1 I observed hackbench testcase
>> took too long to complete (32 vcpu kvm guest on 32 core HT off machine).
>>
>> hackbench 1x degraded by 3 time (40sec vs 112sec)
>> hackbench 2x degraded by around 20time (90sec vs 1800 sec)
>>
>> When I bisected, I found that I had CONFIG_SLUB_CPU_PARTIAL
>> accidentally disabled.
>> I understand that CONFIG_SLUB_CPU_PARTIAL=y by default and the config
>> option is to provide determinism for RT kernels and thus it is not a
>> problem.
>> But thought of sharing this here so that if somebody runs into same
>> issue accidently, it would save their time.
>
> Incidentally, what difference do you currently get with SLUB and SLAB ?
>
tested now,
hackbench 1x is almost 2 times slower (40 vs 93)
hackbench 2x is almost 6times slower (90sec vs 528)
prev parent reply other threads:[~2013-07-25 13:13 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-25 8:00 Hack bench regression with CONFIG_SLUB_CPU_PARTIAL disabled (info only) Raghavendra K T
2013-07-25 11:05 ` Eric Dumazet
2013-07-25 13:20 ` Raghavendra K T [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51F1263A.6070704@linux.vnet.ibm.com \
--to=raghavendra.kt@linux.vnet.ibm.com \
--cc=davem@davemloft.net \
--cc=ebiederm@xmission.com \
--cc=edumazet@google.com \
--cc=eric.dumazet@gmail.com \
--cc=gaofeng@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.