[PATCH][RFC] slub: increasing order reduces memory usage of some key caches

[PATCH][RFC] slub: increasing order reduces memory usage of some key caches

[Richard Kennedy]

Hi,

This test patch increases the order of those caches that will gain an
extra object per slab. In particular on 64 bit this effects dentry &
radix_tree_node.

On a freshly booted box after a kernel compile (make clean;make) there
is significant savings in both dentry & radix_tree_node

on my amd64 3 gb ram desktop typical numbers :-

[kernel,objects,pages/slab,slabs,total pages,diff]
radix_tree_node
2.6.26 33922,2,2423 	4846
+patch 33541,4,1165	4660,-186
dentry
2.6.26	82136,1,4323	4323
+patch	79482,2,2038	4076,-247
the extra dentries would use 136 pages but that still leaves a saving of
111 pages.

I see some improvement in iozone write/rewrite numbers particularly
apparent at the beginning of a run (I guess when there are no dirty
pages ?). 

I've also run this patch on my old laptop( Pentuim M 384Mb ram) & it
works with no problems. After a kernel make there's not much difference
in the used memory but I think I'm seeing a improvement in the elapsed
time. 35 minutes -> 33 minutes. However I've not run this enough times
to tell if this is just luck or noise!   

I've been running this on my desktop for several weeks without any
problems.

Can anyone suggest any other tests that would be useful to run?
& Is there any way to measure what impact this is having on
fragmentation?

Patch against 2.6.26 git.

Thanks
Richard




diff --git a/mm/slub.c b/mm/slub.c
index 315c392..c365b04 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2301,6 +2301,14 @@ static int calculate_sizes(struct kmem_cache *s, int forced_order)
 	if (order < 0)
 		return 0;
 
+	if (order < slub_max_order ) {
+		unsigned long waste = (PAGE_SIZE << order) % size;
+		if ( waste *2 >= size ) {
+			order++;
+			printk ( KERN_INFO "SLUB: increasing order %s->[%d] [%ld]\n",s->name,order,size);
+		}
+	}
+
 	s->allocflags = 0;
 	if (order)
 		s->allocflags |= __GFP_COMP;


--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][RFC] slub: increasing order reduces memory usage of some key caches

[Christoph Lameter]

Richard Kennedy wrote:


> on my amd64 3 gb ram desktop typical numbers :-
> 
> [kernel,objects,pages/slab,slabs,total pages,diff]
> radix_tree_node
> 2.6.26 33922,2,2423 	4846
> +patch 33541,4,1165	4660,-186
> dentry
> 2.6.26	82136,1,4323	4323
> +patch	79482,2,2038	4076,-247
> the extra dentries would use 136 pages but that still leaves a saving of
> 111 pages.

Good numbers....

> Can anyone suggest any other tests that would be useful to run?
> & Is there any way to measure what impact this is having on
> fragmentation?

Mel would be able to tell you that but I think we better figure out what went wrong first.


> diff --git a/mm/slub.c b/mm/slub.c
> index 315c392..c365b04 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -2301,6 +2301,14 @@ static int calculate_sizes(struct kmem_cache *s, int forced_order)
>  	if (order < 0)
>  		return 0;
>  
> +	if (order < slub_max_order ) {
> +		unsigned long waste = (PAGE_SIZE << order) % size;
> +		if ( waste *2 >= size ) {
> +			order++;
> +			printk ( KERN_INFO "SLUB: increasing order %s->[%d] [%ld]\n",s->name,order,size);
> +		}
> +	}
> +
>  	s->allocflags = 0;
>  	if (order)
>  		s->allocflags |= __GFP_COMP;

The order and waste calculation occurs in slab_order(). If modifications are needed then they need to occur in that function.

Looks like the existing code is not doing the best thing for dentries on your box?

On my 64 bit box dentries are 208 bytes long, 39 objects per page and 84 bytes
are lost per order 1 page. So this would not trigger your patch at all. There must be something special to your configuration.


/linux-2.6$ slabinfo dentry

Slabcache: dentry                Aliases:  0 Order :  1 Objects: 554209
** Reclaim accounting active

Sizes (bytes)     Slabs              Debug                Memory
------------------------------------------------------------------------
Object :     208  Total  :   14215   Sanity Checks : Off  Total: 116449280
SlabObj:     208  Full   :   14179   Redzoning     : Off  Used : 115275472
SlabSiz:    8192  Partial:      32   Poisoning     : Off  Loss : 1173808
Loss   :       0  CpuSlab:       4   Tracking      : Off  Lalig:       0
Align  :       8  Objects:      39   Tracing       : Off  Lpadd: 1137200


Can you post the slabinfo information about the caches that you are concerned with? Please a before and after state.


--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][RFC] slub: increasing order reduces memory usage of some key caches

[Richard Kennedy]

On Wed, 2008-07-16 at 08:21 -0500, Christoph Lameter wrote:
> Richard Kennedy wrote:
> 
> 
> > on my amd64 3 gb ram desktop typical numbers :-
> > 
> > [kernel,objects,pages/slab,slabs,total pages,diff]
> > radix_tree_node
> > 2.6.26 33922,2,2423 	4846
> > +patch 33541,4,1165	4660,-186
> > dentry
> > 2.6.26	82136,1,4323	4323
> > +patch	79482,2,2038	4076,-247
> > the extra dentries would use 136 pages but that still leaves a saving of
> > 111 pages.
> 
> Good numbers....
> 
> > Can anyone suggest any other tests that would be useful to run?
> > & Is there any way to measure what impact this is having on
> > fragmentation?
> 
> Mel would be able to tell you that but I think we better figure out what went wrong first.
> 
> 
> > diff --git a/mm/slub.c b/mm/slub.c
> > index 315c392..c365b04 100644
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -2301,6 +2301,14 @@ static int calculate_sizes(struct kmem_cache *s, int forced_order)
> >  	if (order < 0)
> >  		return 0;
> >  
> > +	if (order < slub_max_order ) {
> > +		unsigned long waste = (PAGE_SIZE << order) % size;
> > +		if ( waste *2 >= size ) {
> > +			order++;
> > +			printk ( KERN_INFO "SLUB: increasing order %s->[%d] [%ld]\n",s->name,order,size);
> > +		}
> > +	}
> > +
> >  	s->allocflags = 0;
> >  	if (order)
> >  		s->allocflags |= __GFP_COMP;
> 
> The order and waste calculation occurs in slab_order(). If modifications are needed then they need to occur in that function.

Definitely -- this was only intended demonstration code :)  

> Looks like the existing code is not doing the best thing for dentries on your box?
> 
> On my 64 bit box dentries are 208 bytes long, 39 objects per page and 84 bytes
> are lost per order 1 page. So this would not trigger your patch at all. There must be something special to your configuration.
> 
It's a slightly modified fedora config -- I'm not aware of anything
particularly special. I'm setting the processor type to amd
athlon64/opteron (CONFIG_MK8) 

> 
> /linux-2.6$ slabinfo dentry
> 
> Slabcache: dentry                Aliases:  0 Order :  1 Objects: 554209
> ** Reclaim accounting active
> 
> Sizes (bytes)     Slabs              Debug                Memory
> ------------------------------------------------------------------------
> Object :     208  Total  :   14215   Sanity Checks : Off  Total: 116449280
> SlabObj:     208  Full   :   14179   Redzoning     : Off  Used : 115275472
> SlabSiz:    8192  Partial:      32   Poisoning     : Off  Loss : 1173808
> Loss   :       0  CpuSlab:       4   Tracking      : Off  Lalig:       0
> Align  :       8  Objects:      39   Tracing       : Off  Lpadd: 1137200
> 
> 
> Can you post the slabinfo information about the caches that you are concerned with? Please a before and after state.
> 
I don't have SYSFS slab info turned on right now, But I'll rebuild and get those for you.

but I get this from /proc/slabinfo

before
dentry             82136  82137    208   19    1 : tunables    0    0    0 : slabdata   4323   4323      0
after
dentry             79482  79482    208   39    2 : tunables    0    0    0 : slabdata   2038   2038      0

Richard

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][RFC] slub: increasing order reduces memory usage of some key caches

[Christoph Lameter]

Richard Kennedy wrote:

> before
> dentry             82136  82137    208   19    1 : tunables    0    0    0 : slabdata   4323   4323      0
> after
> dentry             79482  79482    208   39    2 : tunables    0    0    0 : slabdata   2038   2038      0

19 objects with an order 1 alloc and 208 byte size? Urgh. 8192/208 = 39 and not 19.

Kmemcheck or something else active? We seem to be loosing 50% of our memory.

Pekka: Is the slabinfo emulation somehow broken?

I'd really like to see the output of slabinfo dentry.


--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][RFC] slub: increasing order reduces memory usage of some key caches

[Richard Kennedy]

On Wed, 2008-07-16 at 09:03 -0500, Christoph Lameter wrote:
> Richard Kennedy wrote:
> 
> > before
> > dentry             82136  82137    208   19    1 : tunables    0    0    0 : slabdata   4323   4323      0
> > after
> > dentry             79482  79482    208   39    2 : tunables    0    0    0 : slabdata   2038   2038      0
> 
> 19 objects with an order 1 alloc and 208 byte size? Urgh. 8192/208 = 39 and not 19.
> 
> Kmemcheck or something else active? We seem to be loosing 50% of our memory.
> 
> Pekka: Is the slabinfo emulation somehow broken?
> 
> I'd really like to see the output of slabinfo dentry.
> 
/proc/slabinfo says it shows pages/slab not order -- so the numbers are consistent if nothing else.

I'm getting the log message 
> SLUB: increasing order dentry->[1] [208]
from my code, so it looks correct. It's just the standard code is
picking order 0.

I'm just rebuilding the kernel & will get you that slabinfo

Richard 

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][RFC] slub: increasing order reduces memory usage of some key caches

[Vegard Nossum]

On Wed, Jul 16, 2008 at 4:03 PM, Christoph Lameter
<cl@linux-foundation.org> wrote:
> Richard Kennedy wrote:
>
>> before
>> dentry             82136  82137    208   19    1 : tunables    0    0    0 : slabdata   4323   4323      0
>> after
>> dentry             79482  79482    208   39    2 : tunables    0    0    0 : slabdata   2038   2038      0
>
> 19 objects with an order 1 alloc and 208 byte size? Urgh. 8192/208 = 39 and not 19.
>
> Kmemcheck or something else active? We seem to be loosing 50% of our memory.

Hm, I don't think so? I thought that those 1 and 2 were not orders,
but in fact the number of pages. Which seems correct, since now you
have 4096 / 208 = 19 :-)

(His patch bumps order from 0 to 1, so the number of pages were bumped
from 1 to 2.)

Or..?


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][RFC] slub: increasing order reduces memory usage of some key caches

[Christoph Lameter]

Vegard Nossum wrote:

> Hm, I don't think so? I thought that those 1 and 2 were not orders,
> but in fact the number of pages. Which seems correct, since now you
> have 4096 / 208 = 19 :-)

Makes sense. So the problem is that for some reason his kernel chose order 0 for dentries. Mine choose order 1 and everything was fine. Maybe related to the number of processors (my box has 8)? We added some logic in 2.6.26 to increase slab sizes if lots of processors are present.

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][RFC] slub: increasing order reduces memory usage of some key caches

[Richard Kennedy]

On Wed, 2008-07-16 at 09:03 -0500, Christoph Lameter wrote:
> Richard Kennedy wrote:
> 
> > before
> > dentry             82136  82137    208   19    1 : tunables    0    0    0 : slabdata   4323   4323      0
> > after
> > dentry             79482  79482    208   39    2 : tunables    0    0    0 : slabdata   2038   2038      0
> 
> 19 objects with an order 1 alloc and 208 byte size? Urgh. 8192/208 = 39 and not 19.
> 
> Kmemcheck or something else active? We seem to be loosing 50% of our memory.
> 
> Pekka: Is the slabinfo emulation somehow broken?
> 
> I'd really like to see the output of slabinfo dentry.
> 

here's that slabinfo for dentry

on 2.6.26
after booting & starting X

Slabcache: dentry                Aliases:  0 Order :  0 Objects: 22553
** Reclaim accounting active

Sizes (bytes)     Slabs              Debug                Memory
------------------------------------------------------------------------
Object :     208  Total  :    1188   Sanity Checks : Off  Total: 4866048
SlabObj:     208  Full   :    1186   Redzoning     : Off  Used : 4691024
SlabSiz:    4096  Partial:       0   Poisoning     : Off  Loss :  175024
Loss   :       0  CpuSlab:       2   Tracking      : Off  Lalig:       0
Align  :       8  Objects:      19   Tracing       : Off  Lpadd:  171072

and after a make kernel & a small delay

dentry: No NUMA information available.

Slabcache: radix_tree_node       Aliases:  0 Order :  1 Objects: 33564
** Reclaim accounting active

Sizes (bytes)     Slabs              Debug                Memory
------------------------------------------------------------------------
Object :     552  Total  :    2399   Sanity Checks : Off  Total: 19652608
SlabObj:     560  Full   :    2391   Redzoning     : Off  Used : 18527328
SlabSiz:    8192  Partial:       6   Poisoning     : Off  Loss : 1125280
Loss   :       8  CpuSlab:       2   Tracking      : Off  Lalig:  268512
Align  :       0  Objects:      14   Tracing       : Off  Lpadd:  844448

*************
on 2.6.26 + my patch

Slabcache: dentry                Aliases:  0 Order :  1 Objects: 22581
** Reclaim accounting active

Sizes (bytes)     Slabs              Debug                Memory
------------------------------------------------------------------------
Object :     208  Total  :     579   Sanity Checks : Off  Total: 4743168
SlabObj:     208  Full   :     577   Redzoning     : Off  Used : 4696848
SlabSiz:    8192  Partial:       0   Poisoning     : Off  Loss :   46320
Loss   :       0  CpuSlab:       2   Tracking      : Off  Lalig:       0
Align  :       8  Objects:      39   Tracing       : Off  Lpadd:   46320

after the make
Slabcache: dentry                Aliases:  0 Order :  1 Objects: 80168
** Reclaim accounting active

Sizes (bytes)     Slabs              Debug                Memory
------------------------------------------------------------------------
Object :     208  Total  :    2056   Sanity Checks : Off  Total: 16842752
SlabObj:     208  Full   :    2043   Redzoning     : Off  Used : 16674944
SlabSiz:    8192  Partial:      11   Poisoning     : Off  Loss :  167808
Loss   :       0  CpuSlab:       2   Tracking      : Off  Lalig:       0
Align  :       8  Objects:      39   Tracing       : Off  Lpadd:  164480


Richard

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][RFC] slub: increasing order reduces memory usage of some key caches

[Christoph Lameter]

Richard Kennedy wrote:

> Slabcache: dentry                Aliases:  0 Order :  0 Objects: 22553
> ** Reclaim accounting active
> 
> Sizes (bytes)     Slabs              Debug                Memory
> ------------------------------------------------------------------------
> Object :     208  Total  :    1188   Sanity Checks : Off  Total: 4866048
> SlabObj:     208  Full   :    1186   Redzoning     : Off  Used : 4691024
> SlabSiz:    4096  Partial:       0   Poisoning     : Off  Loss :  175024
> Loss   :       0  CpuSlab:       2   Tracking      : Off  Lalig:       0
> Align  :       8  Objects:      19   Tracing       : Off  Lpadd:  171072

So we are using 1188 pages before make

> and after a make kernel & a small delay

2399 pages after make

> on 2.6.26 + my patch

579 * 2 = 1158 (saved 30 pages even before doing anything) before make


> after the make

2025 *2 = 4050 pages which are much more than the 2399 with order 0.
So we are wasting a lot more space. You'd probably need to run slab defrag to get that memory back.

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][RFC] slub: increasing order reduces memory usage of some key caches

[Christoph Lameter]

Richard Kennedy wrote:

> Slabcache: radix_tree_node       Aliases:  0 Order :  1 Objects: 33564

Argh. Should this not be the dentry cache? Wrong numbers?


--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][RFC] slub: increasing order reduces memory usage of some key caches

[Richard Kennedy]

On Fri, 2008-07-18 at 09:20 -0500, Christoph Lameter wrote:
> Richard Kennedy wrote:
> 
> > Slabcache: radix_tree_node       Aliases:  0 Order :  1 Objects: 33564
> 
> Argh. Should this not be the dentry cache? Wrong numbers?
> 
> 
sorry -- yes I cut & pasted the wrong set.

**2.6.26
Slabcache: dentry                Aliases:  0 Order :  0 Objects: 22553
** Reclaim accounting active

Sizes (bytes)     Slabs              Debug                Memory
------------------------------------------------------------------------
Object :     208  Total  :    1188   Sanity Checks : Off  Total: 4866048
SlabObj:     208  Full   :    1186   Redzoning     : Off  Used : 4691024
SlabSiz:    4096  Partial:       0   Poisoning     : Off  Loss :  175024
Loss   :       0  CpuSlab:       2   Tracking      : Off  Lalig:       0
Align  :       8  Objects:      19   Tracing       : Off  Lpadd:  171072

**after make
Slabcache: dentry                Aliases:  0 Order :  0 Objects: 80076
** Reclaim accounting active

Sizes (bytes)     Slabs              Debug                Memory
------------------------------------------------------------------------
Object :     208  Total  :    4215   Sanity Checks : Off  Total: 17264640
SlabObj:     208  Full   :    4205   Redzoning     : Off  Used : 16655808
SlabSiz:    4096  Partial:       8   Poisoning     : Off  Loss :  608832
Loss   :       0  CpuSlab:       2   Tracking      : Off  Lalig:       0
Align  :       8  Objects:      19   Tracing       : Off  Lpadd:  606960


--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][RFC] slub: increasing order reduces memory usage of some key caches

[Christoph Lameter]

OK that is now 4215 pages before and 4112 after the patch? Yawn.... So barely any effect?

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][RFC] slub: increasing order reduces memory usage of some key caches

[Richard Kennedy]

On Fri, 2008-07-18 at 09:55 -0500, Christoph Lameter wrote:
> OK that is now 4215 pages before and 4112 after the patch? Yawn.... So barely any effect?

Well it's not huge but there's another 100+ pages out of radix_tree,
too. & I've not inspected the rest of the cache usage.

I hope there's nowhere in the kernel wasting large amounts of memory --
that's what userspace is for ;) 


--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][RFC] slub: increasing order reduces memory usage of some key caches

[Christoph Lameter]

Richard Kennedy wrote:
> On Fri, 2008-07-18 at 09:55 -0500, Christoph Lameter wrote:
>> OK that is now 4215 pages before and 4112 after the patch? Yawn.... So barely any effect?
> 
> Well it's not huge but there's another 100+ pages out of radix_tree,
> too. & I've not inspected the rest of the cache usage.

Can you post these numbers with the slabinfo for the radix tree as well? It may be that there are a lot of sparsely populated slab pages that waste memory.





--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][RFC] slub: increasing order reduces memory usage of some key caches

[Mel Gorman]

On (16/07/08 08:21), Christoph Lameter didst pronounce:
> Richard Kennedy wrote:
> 
> 
> > on my amd64 3 gb ram desktop typical numbers :-
> > 
> > [kernel,objects,pages/slab,slabs,total pages,diff]
> > radix_tree_node
> > 2.6.26 33922,2,2423 	4846
> > +patch 33541,4,1165	4660,-186
> > dentry
> > 2.6.26	82136,1,4323	4323
> > +patch	79482,2,2038	4076,-247
> > the extra dentries would use 136 pages but that still leaves a saving of
> > 111 pages.
> 
> Good numbers....
> 

Indeed. clearly internal fragmentation is a problem.

> > Can anyone suggest any other tests that would be useful to run?
> > & Is there any way to measure what impact this is having on
> > fragmentation?
> 
> Mel would be able to tell you that but I think we better figure out what went wrong first.
> 

For internal fragmentation, there is this crappy script:
http://www.csn.ul.ie/~mel/intfrag_stat

run it as intfrag_stat -a and it should tell you what precentage of
memory is being wasted for dentries. The patch should show a difference
for the dentries.

How it would affect external fragmentation is harder to guess. It will
put more pressure for high-order allocations but at a glance, dentries
are using GFP_KERNEL so it should not be a major problem.
/proc/pagetypeinfo is the file to watch. If the count for "reclaimable"
arenas is higher and climbing over time, it will indiate that external
fragmentation would eventually become a problem.

> 
> > diff --git a/mm/slub.c b/mm/slub.c
> > index 315c392..c365b04 100644
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -2301,6 +2301,14 @@ static int calculate_sizes(struct kmem_cache *s, int forced_order)
> >  	if (order < 0)
> >  		return 0;
> >  
> > +	if (order < slub_max_order ) {
> > +		unsigned long waste = (PAGE_SIZE << order) % size;
> > +		if ( waste *2 >= size ) {
> > +			order++;
> > +			printk ( KERN_INFO "SLUB: increasing order %s->[%d] [%ld]\n",s->name,order,size);
> > +		}
> > +	}
> > +
> >  	s->allocflags = 0;
> >  	if (order)
> >  		s->allocflags |= __GFP_COMP;
> 
> The order and waste calculation occurs in slab_order(). If modifications are needed then they need to occur in that function.
> 
> Looks like the existing code is not doing the best thing for dentries on your box?
> 
> On my 64 bit box dentries are 208 bytes long, 39 objects per page and 84 bytes
> are lost per order 1 page. So this would not trigger your patch at all. There must be something special to your configuration.
> 
> 
> /linux-2.6$ slabinfo dentry
> 
> Slabcache: dentry                Aliases:  0 Order :  1 Objects: 554209
> ** Reclaim accounting active
> 
> Sizes (bytes)     Slabs              Debug                Memory
> ------------------------------------------------------------------------
> Object :     208  Total  :   14215   Sanity Checks : Off  Total: 116449280
> SlabObj:     208  Full   :   14179   Redzoning     : Off  Used : 115275472
> SlabSiz:    8192  Partial:      32   Poisoning     : Off  Loss : 1173808
> Loss   :       0  CpuSlab:       4   Tracking      : Off  Lalig:       0
> Align  :       8  Objects:      39   Tracing       : Off  Lpadd: 1137200
> 
> 
> Can you post the slabinfo information about the caches that you are concerned with? Please a before and after state.
> 
> 
> --
> 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/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
> 

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][RFC] slub: increasing order reduces memory usage of some key caches

[Richard Kennedy]

On Wed, 2008-07-16 at 20:52 +0100, Mel Gorman wrote:
> On (16/07/08 08:21), Christoph Lameter didst pronounce:
> > Richard Kennedy wrote:
> > 
> > 
> > > on my amd64 3 gb ram desktop typical numbers :-
> > > 
> > > [kernel,objects,pages/slab,slabs,total pages,diff]
> > > radix_tree_node
> > > 2.6.26 33922,2,2423 	4846
> > > +patch 33541,4,1165	4660,-186
> > > dentry
> > > 2.6.26	82136,1,4323	4323
> > > +patch	79482,2,2038	4076,-247
> > > the extra dentries would use 136 pages but that still leaves a saving of
> > > 111 pages.
> > 
> > Good numbers....
> > 
> 
> Indeed. clearly internal fragmentation is a problem.
> 
> > > Can anyone suggest any other tests that would be useful to run?
> > > & Is there any way to measure what impact this is having on
> > > fragmentation?
> > 
> > Mel would be able to tell you that but I think we better figure out what went wrong first.
> > 
> 
> For internal fragmentation, there is this crappy script:
> http://www.csn.ul.ie/~mel/intfrag_stat
> 
> run it as intfrag_stat -a and it should tell you what precentage of
> memory is being wasted for dentries. The patch should show a difference
> for the dentries.
> 
> How it would affect external fragmentation is harder to guess. It will
> put more pressure for high-order allocations but at a glance, dentries
> are using GFP_KERNEL so it should not be a major problem.
> /proc/pagetypeinfo is the file to watch. If the count for "reclaimable"
> arenas is higher and climbing over time, it will indiate that external
> fragmentation would eventually become a problem.
> 
Mel,
Thanks for the info & the script. I'll give it a try & see what we get.
Richard


--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][RFC] slub: increasing order reduces memory usage of some key caches

[Christoph Lameter]

You can get a similar effect by booting with a kernel parameter slub_min_objects=20 or so.

The fundamental difference in your patch is that you check for the wasted space in terms of a fraction of the size of a single object whereas the current logic only checks in terms of fractions of a page.

We could add an additional condition that the wasted space be no larger than half an object?

Affected slab configurations 

24 byte sized caches now become an order 1 cache.
72 byte sizes caches now become order 3
96 byte 0 - > 1
320 1 -> 2
448 2 -> 3

buffer_head 0 -> 1
idr_layer_cache 2 -> 3
inode_cache 2 -> 3
journal_*  1 -> 2

etc

So the effect would be a significant enlargement of caches.

In general the speed of slub is bigger the larger the allocations it can get from the page allocator. The page allocators performance is pretty slow compared to slub alloc logic so its a win to minimize calls to it. However, that in turn will put pressure on
larger page allocations.

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][RFC] slub: increasing order reduces memory usage of some key caches

[Christoph Lameter]

Patch to do this the right way in slub:

Index: linux-2.6/mm/slub.c
===================================================================
--- linux-2.6.orig/mm/slub.c	2008-07-16 10:42:07.000000000 -0500
+++ linux-2.6/mm/slub.c	2008-07-16 10:53:36.000000000 -0500
@@ -1860,6 +1860,10 @@
 
 		rem = slab_size % size;
 
+		/* Never waste more than half of the size of an object*/
+		if (rem > size / 2)
+			continue;
+
 		if (rem <= slab_size / fract_leftover)
 			break;
 

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][RFC] slub: increasing order reduces memory usage of some key caches

[Richard Kennedy]

On Wed, 2008-07-16 at 10:59 -0500, Christoph Lameter wrote:
> Patch to do this the right way in slub:
> 
> Index: linux-2.6/mm/slub.c
> ===================================================================
> --- linux-2.6.orig/mm/slub.c	2008-07-16 10:42:07.000000000 -0500
> +++ linux-2.6/mm/slub.c	2008-07-16 10:53:36.000000000 -0500
> @@ -1860,6 +1860,10 @@
>  
>  		rem = slab_size % size;
>  
> +		/* Never waste more than half of the size of an object*/
> +		if (rem > size / 2)
> +			continue;
> +
>  		if (rem <= slab_size / fract_leftover)
>  			break;

Thanks, I'll give that a try.

Do we need to limit the number of times this applies though?

for example, 216 byte structures will give

order:objs/slab:waste
0 :  18 :208
1 :  37 :200
2 :  75 :184
3 : 151 :152
4 : 303 : 88

I'm not sure where the balance point between efficient memory usage &
fragmentation pressure lies, but my gut feeling is that order 4 is just
too big for a structure this small.  

Richard

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][RFC] slub: increasing order reduces memory usage of some key caches

[Christoph Lameter]

Richard Kennedy wrote:

> Thanks, I'll give that a try.
> 
> Do we need to limit the number of times this applies though?

Well so far I am not sure that it is useful to tune caches based on a waste calculation that is object size based. We know that larger page sizes are beneficial for performance so the results are not that surprising.

We could rethink the automatic slab size configuration. Maybe add a memory size based component? If we have more than 512M then double slub_min_objects?

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][RFC] slub: increasing order reduces memory usage of some key caches

[Richard Kennedy]

On Thu, 2008-07-17 at 11:56 -0500, Christoph Lameter wrote:
> Richard Kennedy wrote:
> 
> > Thanks, I'll give that a try.
> > 
> > Do we need to limit the number of times this applies though?
> 
> Well so far I am not sure that it is useful to tune caches based on a
> waste calculation that is object size based. We know that larger page
> sizes are beneficial for performance so the results are not that
> surprising.
> 
> We could rethink the automatic slab size configuration. Maybe add a
> memory size based component? If we have more than 512M then double
> slub_min_objects?

That should help :)  

I just wonder if it's too simple though? There's such a wide range of
hardware configurations & workloads it could be difficult to pick a
one-size-fits-all solution.

I wonder if something more dynamic is needed ?

Slub is already smart enough to handle variable order slabs, so could it
pick the order based on the rate of growth of a cache & the free memory
available?
But tuning such an algorithm might be fun! ;)

Richard

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH][RFC] slub: increasing order reduces memory usage of some key caches

[Christoph Lameter]

Richard Kennedy wrote:

>> We could rethink the automatic slab size configuration. Maybe add a
>> memory size based component? If we have more than 512M then double
>> slub_min_objects?
> 
> That should help :)  
> 
> I just wonder if it's too simple though? There's such a wide range of
> hardware configurations & workloads it could be difficult to pick a
> one-size-fits-all solution.
> 
> I wonder if something more dynamic is needed ?

If you have the time to work on it then go ahead.

> Slub is already smart enough to handle variable order slabs, so could it
> pick the order based on the rate of growth of a cache & the free memory
> available?
> But tuning such an algorithm might be fun! ;)

Sure it could do that. We just need a smart person that has fun tuning such an algorithm until its mature for upstream inclusion.


--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>