lkml.org 
[lkml]   [2008]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: hackbench regression since 2.6.25-rc
From
Date
On Thu, 2008-03-13 at 23:32 -0700, Christoph Lameter wrote:
> On Fri, 14 Mar 2008, Zhang, Yanmin wrote:
>
> > After testing:
> > Name Objects Alloc Free %Fast
> > :0000192 3428 80093958 80090708 92 8
> > :0000512 374 80016030 80015715 68 7
>
> Ahhh... Okay those slabs did not change for 2.6.25-rc. Is there
> really a difference to 2.6.24?
As oprofile shows slub functions spend more than 80% cpu time, I would like
to focus on optimizing SLUB before going back to 2.6.24.

>
> > So block 192 and 512's and very active and their fast free percentage is low.
>
> Yes but that is to be expected given that hackbench does allocate objects
> and then passes them to other processors for freeing.
>
> Could you get me more details on the two critical slabs?
Yes, definitely.

>
> Do slabinfo -a and then pick one alias for each of those sizes.
They are skbuff_head_cache and kmalloc-512.

>
> Then do
>
> slabinfo skbuff_head (whatever alias you want to use to refer to the slab)
Slabcache: skbuff_head_cache Aliases: 7 Order : 0 Objects: 2848

Sizes (bytes) Slabs Debug Memory
------------------------------------------------------------------------
Object : 192 Total : 142 Sanity Checks : Off Total: 581632
SlabObj: 192 Full : 126 Redzoning : Off Used : 546816
SlabSiz: 4096 Partial: 0 Poisoning : Off Loss : 34816
Loss : 0 CpuSlab: 16 Tracking : Off Lalig: 0
Align : 8 Objects: 21 Tracing : Off Lpadd: 9088

skbuff_head_cache has no kmem_cache operations

skbuff_head_cache: Kernel object allocation
-----------------------------------------------------------------------
No Data

skbuff_head_cache: Kernel object freeing
------------------------------------------------------------------------
No Data

skbuff_head_cache: No NUMA information available.

Slab Perf Counter Alloc Free %Al %Fr
--------------------------------------------------
Fastpath 74048234 6259131 92 7
Slowpath 6031994 73818377 7 92
Page Alloc 19746 19603 0 0
Add partial 0 4658709 0 5
Remove partial 4639106 19603 5 0
RemoteObj/SlabFrozen 0 3887872 0 4
Total 80080228 80077508

Refill 6031979
Deactivate Full=4658836(100%) Empty=0(0%) ToHead=0(0%) ToTail=0(0%)




Slabcache: kmalloc-512 Aliases: 1 Order : 0 Objects: 365

Sizes (bytes) Slabs Debug Memory
------------------------------------------------------------------------
Object : 512 Total : 61 Sanity Checks : Off Total: 249856
SlabObj: 512 Full : 36 Redzoning : Off Used : 186880
SlabSiz: 4096 Partial: 9 Poisoning : Off Loss : 62976
Loss : 0 CpuSlab: 16 Tracking : Off Lalig: 0
Align : 8 Objects: 8 Tracing : Off Lpadd: 0

kmalloc-512 has no kmem_cache operations

kmalloc-512: Kernel object allocation
-----------------------------------------------------------------------
No Data

kmalloc-512: Kernel object freeing
------------------------------------------------------------------------
No Data

kmalloc-512: No NUMA information available.

Slab Perf Counter Alloc Free %Al %Fr
--------------------------------------------------
Fastpath 55039159 5006829 68 6
Slowpath 24975754 75007769 31 93
Page Alloc 73840 73779 0 0
Add partial 0 24341085 0 30
Remove partial 24267297 73779 30 0
RemoteObj/SlabFrozen 0 953614 0 1
Total 80014913 80014598

Refill 24975738
Deactivate Full=24341121(100%) Empty=0(0%) ToHead=0(0%) ToTail=0(0%)


>
> for each of them. Should give some more insight as to how slub behaves
> with these two slab caches.
>



\
 
 \ /
  Last update: 2008-03-14 08:19    [W:0.082 / U:27.808 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site