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 kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
