Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Mel Gorman]

On Mon, Jun 08, 2009 at 04:58:10PM +0300, Pekka J Enberg wrote:
> Hi Mel,
> 
> On Mon, 8 Jun 2009, Mel Gorman wrote:
> > Is there any chance you could hatchet together a patch
> > slab-allocation-failure that reports on slab allocation failures similar
> > to what the page allocator does? Minimally, it should tell us what
> > the size of the allocation was but any other information such as the
> > same of the slab, the size of pages it normally uses are, etc. would
> > also be useful.
> 
> Would something like this be sufficient? Figuring out the actual _size_ 
> passed to kmalloc() is pretty difficult as then we would need to do the 
> NULL test in fastpath code or pass the argument deeper in the call-chain.
> 

It's much better than nothing. In the event of an allocation failure, we'll
know which kmalloc bucket it's coming out of so we'll have a limited range
of possible buffer sizes.

I have some suggestions on what we're outputting though.

> 			Pekka
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index 65ffda5..b5acf18 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -1565,6 +1565,8 @@ new_slab:
>  		c->page = new;
>  		goto load_freelist;
>  	}
> +	printk(KERN_WARNING "SLUB: unable to satisfy allocation for cache %s (size=%d, node=%d, gfp=%x)\n",
> +		s->name, s->size, node, gfpflags);

size could be almost anything here for a casual reader. You are
outputting the size of the object plus its metadata so the name should
reflect that. I think it would be better to output objsize= and the
object size without the metadata overhead. What do you think?

In addition, include how many objects there are per-slab and include what
the order is being passed to the page allocator when allocating new slabs.
Would that be enough to determine if fallback-to-smaller orders occured?

>  	return NULL;
>  debug:
>  	if (!alloc_debug_processing(s, c->page, object, addr))
> 

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/