> > > > > 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@xxxxxxxxx. 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@xxxxxxxxx";> email@xxxxxxxxx </a>