lkml.org 
[lkml]   [2007]   [Jun]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: [patch 00/12] Slab defragmentation V3
    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/
    \
     
     \ /
      Last update: 2007-06-08 21:41    [W:2.837 / U:0.148 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site