[PATCH -v2] mm: SLAB Out-of-memory diagnostics

[PATCH -v2] mm: SLAB Out-of-memory diagnostics

[Rafael Aquini]

Following the example at mm/slub.c, add out-of-memory diagnostics to the
SLAB allocator to help on debugging certain OOM conditions.

An example print out looks like this:

  <snip page allocator out-of-memory message>
  SLAB: Unable to allocate memory on node 0 (gfp=0x11200)
     cache: bio-0, object size: 192, order: 0
     node0: slabs: 3/3, objs: 60/60, free: 0

Signed-off-by: Rafael Aquini <aquini@redhat.com>
---
-v2:
* drop the sysctl knob to override __GFP_NOWARN allocation flag.

 mm/slab.c |   51 ++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 50 insertions(+), 1 deletions(-)

diff --git a/mm/slab.c b/mm/slab.c
index f0bd785..4aeb5e7 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -1731,6 +1731,52 @@ static int __init cpucache_init(void)
 }
 __initcall(cpucache_init);
 
+static noinline void
+slab_out_of_memory(struct kmem_cache *cachep, gfp_t gfpflags, int nodeid)
+{
+	struct kmem_list3 *l3;
+	struct slab *slabp;
+	unsigned long flags;
+	int node;
+
+	printk(KERN_WARNING
+		"SLAB: Unable to allocate memory on node %d (gfp=0x%x)\n",
+		nodeid, gfpflags);
+	printk(KERN_WARNING "   cache: %s, object size: %d, order: %d\n",
+		cachep->name, cachep->buffer_size, cachep->gfporder);
+
+	for_each_online_node(node) {
+		unsigned long active_objs = 0, num_objs = 0, free_objects = 0;
+		unsigned long active_slabs = 0, num_slabs = 0;
+
+		l3 = cachep->nodelists[node];
+		if (!l3)
+			continue;
+
+		spin_lock_irqsave(&l3->list_lock, flags);
+		list_for_each_entry(slabp, &l3->slabs_full, list) {
+			active_objs += cachep->num;
+			active_slabs++;
+		}
+		list_for_each_entry(slabp, &l3->slabs_partial, list) {
+			active_objs += slabp->inuse;
+			active_slabs++;
+		}
+		list_for_each_entry(slabp, &l3->slabs_free, list)
+			num_slabs++;
+
+		free_objects += l3->free_objects;
+		spin_unlock_irqrestore(&l3->list_lock, flags);
+
+		num_slabs += active_slabs;
+		num_objs = num_slabs * cachep->num;
+		printk(KERN_WARNING
+			"   node%d: slabs: %ld/%ld, objs: %ld/%ld, free: %ld\n",
+			node, active_slabs, num_slabs, active_objs, num_objs,
+			free_objects);
+	}
+}
+
 /*
  * Interface to system's page allocator. No need to hold the cache-lock.
  *
@@ -1757,8 +1803,11 @@ static void *kmem_getpages(struct kmem_cache *cachep, gfp_t flags, int nodeid)
 		flags |= __GFP_RECLAIMABLE;
 
 	page = alloc_pages_exact_node(nodeid, flags | __GFP_NOTRACK, cachep->gfporder);
-	if (!page)
+	if (!page) {
+		if (!(flags & __GFP_NOWARN) && printk_ratelimit())
+			slab_out_of_memory(cachep, flags, nodeid);
 		return NULL;
+	}
 
 	nr_pages = (1 << cachep->gfporder);
 	if (cachep->flags & SLAB_RECLAIM_ACCOUNT)
-- 
1.7.7.6

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH -v2] mm: SLAB Out-of-memory diagnostics

[Rik van Riel]

On 03/05/2012 01:10 PM, Rafael Aquini wrote:
> Following the example at mm/slub.c, add out-of-memory diagnostics to the
> SLAB allocator to help on debugging certain OOM conditions.
>
> An example print out looks like this:
>
>    <snip page allocator out-of-memory message>
>    SLAB: Unable to allocate memory on node 0 (gfp=0x11200)
>       cache: bio-0, object size: 192, order: 0
>       node0: slabs: 3/3, objs: 60/60, free: 0
>
> Signed-off-by: Rafael Aquini<aquini@redhat.com>

Acked-by: Rik van Riel <riel@redhat.com>

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH -v2] mm: SLAB Out-of-memory diagnostics

[David Rientjes]

On Mon, 5 Mar 2012, Rafael Aquini wrote:

> diff --git a/mm/slab.c b/mm/slab.c
> index f0bd785..4aeb5e7 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -1731,6 +1731,52 @@ static int __init cpucache_init(void)
>  }
>  __initcall(cpucache_init);
>  
> +static noinline void
> +slab_out_of_memory(struct kmem_cache *cachep, gfp_t gfpflags, int nodeid)
> +{
> +	struct kmem_list3 *l3;
> +	struct slab *slabp;
> +	unsigned long flags;
> +	int node;
> +
> +	printk(KERN_WARNING
> +		"SLAB: Unable to allocate memory on node %d (gfp=0x%x)\n",
> +		nodeid, gfpflags);
> +	printk(KERN_WARNING "   cache: %s, object size: %d, order: %d\n",
> +		cachep->name, cachep->buffer_size, cachep->gfporder);
> +
> +	for_each_online_node(node) {
> +		unsigned long active_objs = 0, num_objs = 0, free_objects = 0;
> +		unsigned long active_slabs = 0, num_slabs = 0;
> +
> +		l3 = cachep->nodelists[node];
> +		if (!l3)
> +			continue;
> +
> +		spin_lock_irqsave(&l3->list_lock, flags);

Could be spin_lock_irq(&l3->list_lock);

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH -v2] mm: SLAB Out-of-memory diagnostics

[Rafael Aquini]

Howdy David,

On Tue, Mar 06, 2012 at 07:41:55PM -0800, David Rientjes wrote:
> > +		spin_lock_irqsave(&l3->list_lock, flags);
> 
> Could be spin_lock_irq(&l3->list_lock);

I don't think it would be safe making such assumption.

Note that spin_lock_irqsave() is used at slab_out_of_memory() because we cannot
guarantee that interrupts will be enabled/disabled by the time kmem_getpages()
is called in cache_grow() or fallback_alloc().

  Rafael

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH -v2] mm: SLAB Out-of-memory diagnostics

[Cong Wang]

On 03/06/2012 02:10 AM, Rafael Aquini wrote:
> Following the example at mm/slub.c, add out-of-memory diagnostics to the
> SLAB allocator to help on debugging certain OOM conditions.
>
> An example print out looks like this:
>
>    <snip page allocator out-of-memory message>
>    SLAB: Unable to allocate memory on node 0 (gfp=0x11200)
>       cache: bio-0, object size: 192, order: 0
>       node0: slabs: 3/3, objs: 60/60, free: 0
>

Nitpick:

What about "node: 0" instead of "node0: " ?

Thanks.

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH -v2] mm: SLAB Out-of-memory diagnostics

[David Rientjes]

On Wed, 7 Mar 2012, Cong Wang wrote:

> > Following the example at mm/slub.c, add out-of-memory diagnostics to the
> > SLAB allocator to help on debugging certain OOM conditions.
> > 
> > An example print out looks like this:
> > 
> >    <snip page allocator out-of-memory message>
> >    SLAB: Unable to allocate memory on node 0 (gfp=0x11200)
> >       cache: bio-0, object size: 192, order: 0
> >       node0: slabs: 3/3, objs: 60/60, free: 0
> > 
> 
> Nitpick:
> 
> What about "node: 0" instead of "node0: " ?
> 

Good catch, that format would match the output of the slub out-of-memory 
messages.

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH -v2] mm: SLAB Out-of-memory diagnostics

[Rafael Aquini]

On Tue, Mar 06, 2012 at 09:42:57PM -0800, David Rientjes wrote:
> On Wed, 7 Mar 2012, Cong Wang wrote:
> 
> > > Following the example at mm/slub.c, add out-of-memory diagnostics to the
> > > SLAB allocator to help on debugging certain OOM conditions.
> > > 
> > > An example print out looks like this:
> > > 
> > >    <snip page allocator out-of-memory message>
> > >    SLAB: Unable to allocate memory on node 0 (gfp=0x11200)
> > >       cache: bio-0, object size: 192, order: 0
> > >       node0: slabs: 3/3, objs: 60/60, free: 0
> > > 
> > 
> > Nitpick:
> > 
> > What about "node: 0" instead of "node0: " ?
> > 
> 
> Good catch, that format would match the output of the slub out-of-memory 
> messages.
>

To be honest, I really don't see a big advantage on the nitpick, however, if we
want to accurately copycat the slub output here, I can insert a blank space
between the word and the digit, like the following:
   "node #: ..."

  Rafael 

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH -v2] mm: SLAB Out-of-memory diagnostics

[Pekka Enberg]

On Wed, Mar 7, 2012 at 4:46 PM, Rafael Aquini <aquini@redhat.com> wrote:
>> > Nitpick:
>> >
>> > What about "node: 0" instead of "node0: " ?
>> >
>>
>> Good catch, that format would match the output of the slub out-of-memory
>> messages.
>>
>
> To be honest, I really don't see a big advantage on the nitpick, however, if we
> want to accurately copycat the slub output here, I can insert a blank space
> between the word and the digit, like the following:
>   "node #: ..."

So if you're interested in getting this patch to v3.4, now would be a
good time to update the patch as per review comments and resend.

                        Pekka

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH v3] mm: SLAB Out-of-memory diagnostics

[Rafael Aquini]

Following the example at mm/slub.c, add out-of-memory diagnostics to the
SLAB allocator to help on debugging certain OOM conditions.

An example print out looks like this:

  <snip page allocator out-of-memory message>
  SLAB: Unable to allocate memory on node 0 (gfp=0x11200)
    cache: bio-0, object size: 192, order: 0
    node 0: slabs: 3/3, objs: 60/60, free: 0

Signed-off-by: Rafael Aquini <aquini@redhat.com>
Acked-by: Rik van Riel <riel@redhat.com>
---
v2:
* drop the sysctl knob to override __GFP_NOWARN allocation flag (Pekka, David)

v3:
* adjust the print output to match slub's warning printout (WANG Cong)

 mm/slab.c |   51 ++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 50 insertions(+), 1 deletions(-)

diff --git a/mm/slab.c b/mm/slab.c
index f0bd785..cda1ff6 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -1731,6 +1731,52 @@ static int __init cpucache_init(void)
 }
 __initcall(cpucache_init);
 
+static noinline void
+slab_out_of_memory(struct kmem_cache *cachep, gfp_t gfpflags, int nodeid)
+{
+	struct kmem_list3 *l3;
+	struct slab *slabp;
+	unsigned long flags;
+	int node;
+
+	printk(KERN_WARNING
+		"SLAB: Unable to allocate memory on node %d (gfp=0x%x)\n",
+		nodeid, gfpflags);
+	printk(KERN_WARNING "  cache: %s, object size: %d, order: %d\n",
+		cachep->name, cachep->buffer_size, cachep->gfporder);
+
+	for_each_online_node(node) {
+		unsigned long active_objs = 0, num_objs = 0, free_objects = 0;
+		unsigned long active_slabs = 0, num_slabs = 0;
+
+		l3 = cachep->nodelists[node];
+		if (!l3)
+			continue;
+
+		spin_lock_irqsave(&l3->list_lock, flags);
+		list_for_each_entry(slabp, &l3->slabs_full, list) {
+			active_objs += cachep->num;
+			active_slabs++;
+		}
+		list_for_each_entry(slabp, &l3->slabs_partial, list) {
+			active_objs += slabp->inuse;
+			active_slabs++;
+		}
+		list_for_each_entry(slabp, &l3->slabs_free, list)
+			num_slabs++;
+
+		free_objects += l3->free_objects;
+		spin_unlock_irqrestore(&l3->list_lock, flags);
+
+		num_slabs += active_slabs;
+		num_objs = num_slabs * cachep->num;
+		printk(KERN_WARNING
+			"  node %d: slabs: %ld/%ld, objs: %ld/%ld, free: %ld\n",
+			node, active_slabs, num_slabs, active_objs, num_objs,
+			free_objects);
+	}
+}
+
 /*
  * Interface to system's page allocator. No need to hold the cache-lock.
  *
@@ -1757,8 +1803,11 @@ static void *kmem_getpages(struct kmem_cache *cachep, gfp_t flags, int nodeid)
 		flags |= __GFP_RECLAIMABLE;
 
 	page = alloc_pages_exact_node(nodeid, flags | __GFP_NOTRACK, cachep->gfporder);
-	if (!page)
+	if (!page) {
+		if (!(flags & __GFP_NOWARN) && printk_ratelimit())
+			slab_out_of_memory(cachep, flags, nodeid);
 		return NULL;
+	}
 
 	nr_pages = (1 << cachep->gfporder);
 	if (cachep->flags & SLAB_RECLAIM_ACCOUNT)
-- 
1.7.7.6

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v3] mm: SLAB Out-of-memory diagnostics

[Pekka Enberg]

On Fri, Mar 9, 2012 at 10:27 PM, Rafael Aquini <aquini@redhat.com> wrote:
> Following the example at mm/slub.c, add out-of-memory diagnostics to the
> SLAB allocator to help on debugging certain OOM conditions.
>
> An example print out looks like this:
>
>  <snip page allocator out-of-memory message>
>  SLAB: Unable to allocate memory on node 0 (gfp=0x11200)
>    cache: bio-0, object size: 192, order: 0
>    node 0: slabs: 3/3, objs: 60/60, free: 0
>
> Signed-off-by: Rafael Aquini <aquini@redhat.com>
> Acked-by: Rik van Riel <riel@redhat.com>

David?

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v3] mm: SLAB Out-of-memory diagnostics

[David Rientjes]

On Fri, 9 Mar 2012, Rafael Aquini wrote:

> Following the example at mm/slub.c, add out-of-memory diagnostics to the
> SLAB allocator to help on debugging certain OOM conditions.
> 
> An example print out looks like this:
> 
>   <snip page allocator out-of-memory message>
>   SLAB: Unable to allocate memory on node 0 (gfp=0x11200)
>     cache: bio-0, object size: 192, order: 0
>     node 0: slabs: 3/3, objs: 60/60, free: 0
> 
> Signed-off-by: Rafael Aquini <aquini@redhat.com>
> Acked-by: Rik van Riel <riel@redhat.com>

Acked-by: David Rientjes <rientjes@google.com>

Thanks for following through with this!

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v3] mm: SLAB Out-of-memory diagnostics

[Pekka Enberg]

> On Fri, 9 Mar 2012, Rafael Aquini wrote:
> 
> > Following the example at mm/slub.c, add out-of-memory diagnostics to the
> > SLAB allocator to help on debugging certain OOM conditions.
> > 
> > An example print out looks like this:
> > 
> >   <snip page allocator out-of-memory message>
> >   SLAB: Unable to allocate memory on node 0 (gfp=0x11200)
> >     cache: bio-0, object size: 192, order: 0
> >     node 0: slabs: 3/3, objs: 60/60, free: 0
> > 
> > Signed-off-by: Rafael Aquini <aquini@redhat.com>
> > Acked-by: Rik van Riel <riel@redhat.com>

On Fri, 9 Mar 2012, David Rientjes wrote:
> Acked-by: David Rientjes <rientjes@google.com>
> 
> Thanks for following through with this!

Applied, thanks guys!

			Pekka

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v3] mm: SLAB Out-of-memory diagnostics

[Eric Dumazet]

On Fri, 2012-03-09 at 17:27 -0300, Rafael Aquini wrote:
> Following the example at mm/slub.c, add out-of-memory diagnostics to the
> SLAB allocator to help on debugging certain OOM conditions.
> 
> An example print out looks like this:
> 
>   <snip page allocator out-of-memory message>
>   SLAB: Unable to allocate memory on node 0 (gfp=0x11200)
>     cache: bio-0, object size: 192, order: 0
>     node 0: slabs: 3/3, objs: 60/60, free: 0

Should probably be :

   node: 0 slabs: 3/3, objs: 60/60, free: 0


> 
> Signed-off-by: Rafael Aquini <aquini@redhat.com>
> Acked-by: Rik van Riel <riel@redhat.com>
> ---
> v2:
> * drop the sysctl knob to override __GFP_NOWARN allocation flag (Pekka, David)
> 
> v3:
> * adjust the print output to match slub's warning printout (WANG Cong)
> 
>  mm/slab.c |   51 ++++++++++++++++++++++++++++++++++++++++++++++++++-
>  1 files changed, 50 insertions(+), 1 deletions(-)
> 
> diff --git a/mm/slab.c b/mm/slab.c
> index f0bd785..cda1ff6 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -1731,6 +1731,52 @@ static int __init cpucache_init(void)
>  }
>  __initcall(cpucache_init);
>  
> +static noinline void
> +slab_out_of_memory(struct kmem_cache *cachep, gfp_t gfpflags, int nodeid)
> +{
> +	struct kmem_list3 *l3;
> +	struct slab *slabp;
> +	unsigned long flags;
> +	int node;
> +
> +	printk(KERN_WARNING
> +		"SLAB: Unable to allocate memory on node %d (gfp=0x%x)\n",
> +		nodeid, gfpflags);
> +	printk(KERN_WARNING "  cache: %s, object size: %d, order: %d\n",
> +		cachep->name, cachep->buffer_size, cachep->gfporder);
> +
> +	for_each_online_node(node) {
> +		unsigned long active_objs = 0, num_objs = 0, free_objects = 0;
> +		unsigned long active_slabs = 0, num_slabs = 0;
> +
> +		l3 = cachep->nodelists[node];
> +		if (!l3)
> +			continue;
> +
> +		spin_lock_irqsave(&l3->list_lock, flags);
> +		list_for_each_entry(slabp, &l3->slabs_full, list) {
> +			active_objs += cachep->num;
> +			active_slabs++;
> +		}
> +		list_for_each_entry(slabp, &l3->slabs_partial, list) {
> +			active_objs += slabp->inuse;
> +			active_slabs++;
> +		}
> +		list_for_each_entry(slabp, &l3->slabs_free, list)
> +			num_slabs++;
> +
> +		free_objects += l3->free_objects;
> +		spin_unlock_irqrestore(&l3->list_lock, flags);
> +
> +		num_slabs += active_slabs;
> +		num_objs = num_slabs * cachep->num;
> +		printk(KERN_WARNING
> +			"  node %d: slabs: %ld/%ld, objs: %ld/%ld, free: %ld\n",

Probably should be :
		"  node: %d slabs: %ld/%ld, objs: %ld/%ld, free: %ld\n",

> +			node, active_slabs, num_slabs, active_objs, num_objs,
> +			free_objects);
> +	}
> +}
> +
>  /*
>   * Interface to system's page allocator. No need to hold the cache-lock.
>   *
> @@ -1757,8 +1803,11 @@ static void *kmem_getpages(struct kmem_cache *cachep, gfp_t flags, int nodeid)
>  		flags |= __GFP_RECLAIMABLE;
>  
>  	page = alloc_pages_exact_node(nodeid, flags | __GFP_NOTRACK, cachep->gfporder);
> -	if (!page)
> +	if (!page) {
> +		if (!(flags & __GFP_NOWARN) && printk_ratelimit())
> +			slab_out_of_memory(cachep, flags, nodeid);
>  		return NULL;
> +	}
>  
>  	nr_pages = (1 << cachep->gfporder);
>  	if (cachep->flags & SLAB_RECLAIM_ACCOUNT)


--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v3] mm: SLAB Out-of-memory diagnostics

[Rafael Aquini]

Howdy Eric,

On Fri, Mar 09, 2012 at 04:23:39PM -0800, Eric Dumazet wrote:
> On Fri, 2012-03-09 at 17:27 -0300, Rafael Aquini wrote:
> > Following the example at mm/slub.c, add out-of-memory diagnostics to the
> > SLAB allocator to help on debugging certain OOM conditions.
> > 
> > An example print out looks like this:
> > 
> >   <snip page allocator out-of-memory message>
> >   SLAB: Unable to allocate memory on node 0 (gfp=0x11200)
> >     cache: bio-0, object size: 192, order: 0
> >     node 0: slabs: 3/3, objs: 60/60, free: 0
> 
> Should probably be :
> 
>    node: 0 slabs: 3/3, objs: 60/60, free: 0
>
 
No it shouldn't. Please refer to https://lkml.org/lkml/2012/3/7/242

The intent here was just to match slub's printout for its slab_out_of_memory 
node list slab components, as one can check on mm/slub.c:

2096                 printk(KERN_WARNING
2097                         "  node %d: slabs: %ld, objs: %ld, free: %ld\n",
2098                         node, nr_slabs, nr_objs, nr_free);


> > +		printk(KERN_WARNING
> > +			"  node %d: slabs: %ld/%ld, objs: %ld/%ld, free: %ld\n",
> 
> Probably should be :
> 		"  node: %d slabs: %ld/%ld, objs: %ld/%ld, free: %ld\n",
>

ditto.


Thanks for your feedback!

	Rafael

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>