Re: hackbench regression since 2.6.25-rc

["Zhang, Yanmin" <yanmin_zhang@linux.intel.com>]

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