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;
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.
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
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.
On Wed, Jul 16, 2008 at 4:03 PM, Christoph Lameter
<[email protected]> 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
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.
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.
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
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 [email protected]. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
>
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
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
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
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.
Richard Kennedy wrote:
> Slabcache: radix_tree_node Aliases: 0 Order : 1 Objects: 33564
Argh. Should this not be the dentry cache? Wrong numbers?
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
OK that is now 4215 pages before and 4112 after the patch? Yawn.... So barely any effect?
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 ;)
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.