Re: [patch 00/12] Slab defragmentation V3

From: Christoph Lameter
Date: Fri Jun 08 2007 - 15:39:06 EST


On Fri, 8 Jun 2007, Michal Piotrowski wrote:

> 0xc1081630 is in list_locations (mm/slub.c:3388).
> 3383 struct page *page;
> 3384
> 3385 if (!atomic_read(&n->nr_slabs))
> 3386 continue;
> 3387
> 3388 spin_lock_irqsave(&n->list_lock, flags);
> 3389 list_for_each_entry(page, &n->partial, lru)
> 3390 process_slab(&t, s, page, alloc);
> 3391 list_for_each_entry(page, &n->full, lru)
> 3392 process_slab(&t, s, page, alloc);


Yes process slab needs some temporary data to generate the lists of
functions calling etc and that is a GFP_TEMPORARY alloc.

Does this fix it?

---
mm/slub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

Index: slub/mm/slub.c
===================================================================
--- slub.orig/mm/slub.c 2007-06-08 12:35:56.000000000 -0700
+++ slub/mm/slub.c 2007-06-08 12:37:32.000000000 -0700
@@ -2930,7 +2930,7 @@ static int alloc_loc_track(struct loc_tr

order = get_order(sizeof(struct location) * max);

- l = (void *)__get_free_pages(GFP_TEMPORARY, order);
+ l = (void *)__get_free_pages(GFP_ATOMIC, order);

if (!l)
return 0;
-
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/