From: "Alex,Shi" <alex.shi@intel.com>
To: "Li, Shaohua" <shaohua.li@intel.com>
Cc: David Rientjes <rientjes@google.com>,
Christoph Lameter <cl@linux.com>,
"penberg@kernel.org" <penberg@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Andi Kleen <ak@linux.intel.com>
Subject: Re: [PATCH 1/3] slub: set a criteria for slub node partial adding
Date: Mon, 12 Dec 2011 14:17:13 +0800 [thread overview]
Message-ID: <1323670633.16790.6131.camel@debian> (raw)
In-Reply-To: <1323665304.22361.392.camel@sli10-conroe>
> > > > > With the per-cpu partial list, I didn't see any workload which is still
> > > > > suffering from the list lock,
> > > >
> > > > The merge error that you fixed in 3.2-rc1 for hackbench regression is
> > > > due to add slub to node partial head. And data of hackbench show node
> > > > partial is still heavy used in allocation.
> > > The patch is already in base kernel, did you mean even with it you still
> > > saw the list locking issue with latest kernel?
> > >
> >
> > Yes, list_lock still hurt performance. It will be helpful if you can do
> > some optimize for it.
> please post data and the workload. In my test, I didn't see the locking
> takes significant time with perf. the slub stat you posted in last mail
> shows most allocation goes the fast path.
>
It is 'hackbench 100 process 2000'
How it's proved there are not locking time on list_lock?
Does the following profile can express sth on slub alloc with my
previous slub stat data?
113517 total 0.0164
11065 unix_stream_recvmsg 5.9425
10862 copy_user_generic_string 169.7188
6011 __alloc_skb 18.7844
5857 __kmalloc_node_track_caller 14.3203
5748 unix_stream_sendmsg 5.4124
4841 kmem_cache_alloc_node 17.3513
4494 skb_release_head_state 34.0455
3697 __slab_free 5.3194
Actually, we know lock content is there, because any change on node
partial list may cause clear performance change on hackbench process
benchmark. But for direct evidence. Any debug may heavy press its using,
and make data unbelievable. So, I'd like hear any suggestions to figure
out it clearly.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-12-12 6:20 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-02 8:23 [PATCH 1/3] slub: set a criteria for slub node partial adding Alex Shi
2011-12-02 8:23 ` [PATCH 2/3] slub: remove unnecessary statistics, deactivate_to_head/tail Alex Shi
2011-12-02 8:23 ` [PATCH 3/3] slub: fill per cpu partial only when free objects larger than one quarter Alex Shi
2011-12-02 14:44 ` [PATCH 2/3] slub: remove unnecessary statistics, deactivate_to_head/tail Christoph Lameter
2011-12-06 21:08 ` David Rientjes
2011-12-02 11:36 ` [PATCH 1/3] slub: set a criteria for slub node partial adding Eric Dumazet
2011-12-02 20:02 ` Christoph Lameter
2011-12-05 2:21 ` Shaohua Li
2011-12-05 10:01 ` Alex,Shi
2011-12-05 3:28 ` Alex,Shi
2011-12-02 14:43 ` Christoph Lameter
2011-12-05 9:22 ` Alex,Shi
2011-12-06 21:06 ` David Rientjes
2011-12-07 5:11 ` Shaohua Li
2011-12-07 7:28 ` David Rientjes
2011-12-12 2:43 ` Shaohua Li
2011-12-12 4:14 ` Alex,Shi
2011-12-12 4:35 ` Shaohua Li
2011-12-12 4:25 ` Alex,Shi
2011-12-12 4:48 ` Shaohua Li
2011-12-12 6:17 ` Alex,Shi [this message]
2011-12-12 6:09 ` Eric Dumazet
2011-12-14 1:29 ` David Rientjes
2011-12-14 2:43 ` Shaohua Li
2011-12-14 2:38 ` David Rientjes
2011-12-09 8:30 ` Alex,Shi
2011-12-09 10:10 ` David Rientjes
2011-12-09 13:40 ` Shi, Alex
2011-12-14 1:38 ` David Rientjes
2011-12-14 2:36 ` David Rientjes
2011-12-14 6:06 ` Alex,Shi
2011-12-14 6:44 ` Eric Dumazet
2011-12-14 6:47 ` Pekka Enberg
2011-12-14 14:53 ` Christoph Lameter
2011-12-14 6:56 ` Alex,Shi
2011-12-14 14:59 ` Christoph Lameter
2011-12-14 17:33 ` Eric Dumazet
2011-12-14 18:26 ` Christoph Lameter
2011-12-13 13:01 ` Shi, Alex
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=1323670633.16790.6131.camel@debian \
--to=alex.shi@intel.com \
--cc=ak@linux.intel.com \
--cc=cl@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=shaohua.li@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).