linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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>

  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 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