On (04/03/08 12:34), Andrew Morton didst pronounce:
> On Tue, 4 Mar 2008 12:07:39 -0800 (PST)
> Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> > I think this is the correct fix.
> >
> > The NUMA fallback logic should be passing local_flags to kmem_get_pages()
> > and not simply the flags.
> >
> > Maybe a stable candidate since we are now simply
> > passing on flags to the page allocator on the fallback path.
>
> Do we know why this is only reported in 2.6.25-rc3-mm1?
>
> Why does this need fixing in 2.6.24.x?
>
I don't believe it needs to be fixed in 2.6.24.3. The call-sites in
lib/radix-tree.c there look like
ret = kmem_cache_alloc(radix_tree_node_cachep,
set_migrateflags(gfp_mask, __GFP_RECLAIMABLE));
node = kmem_cache_alloc(radix_tree_node_cachep,
set_migrateflags(gfp_mask, __GFP_RECLAIMABLE));
and set_migrateflags() looks like
#define GFP_MOVABLE_MASK (__GFP_RECLAIMABLE|__GFP_MOVABLE)
static inline gfp_t set_migrateflags(gfp_t gfp, gfp_t migrate_flags)
{
BUG_ON((gfp & GFP_MOVABLE_MASK) == GFP_MOVABLE_MASK);
return (gfp & ~(GFP_MOVABLE_MASK)) | migrate_flags;
}
so the flags were already getting cleared and the WARN_ON could not
trigger in this path. In 2.6.25-rc3-mm1, the patch
remove-set_migrateflags.patch gets rid of set_migateflags()
which led to this situation.
The surprise is that it didn't get caught in an earlier -mm but it could
be because it only affected slab.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
