linux-kernel - Re: [PATCH 1/3] slub: set a criteria for slub node partial adding

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 12 Dec 2011 14:17:13 +0800
From:	"Alex,Shi" <alex.shi@...el.com>
To:	"Li, Shaohua" <shaohua.li@...el.com>
Cc:	David Rientjes <rientjes@...gle.com>,
	Christoph Lameter <cl@...ux.com>,
	"penberg@...nel.org" <penberg@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	Andi Kleen <ak@...ux.intel.com>
Subject: Re: [PATCH 1/3] slub: set a criteria for slub node partial adding

> > > > > 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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/