Re: [GIT PULL v2] Early SLAB fixes for 2.6.31

[Pekka J Enberg]

On Fri, 12 Jun 2009, Christoph Lameter wrote:
> On Fri, 12 Jun 2009, Pekka J Enberg wrote:
> 
> > @@ -3434,6 +3451,8 @@ __cache_alloc(struct kmem_cache *cachep, gfp_t flags, void *caller)
> >  	unsigned long save_flags;
> >  	void *objp;
> >
> > +	flags &= slab_gfp_mask;
> > +
> >  	lockdep_trace_alloc(flags);
> >
> >  	if (slab_should_failslab(cachep, flags))
> 
> Adds code to hot code path.
> 
> > @@ -1595,6 +1601,8 @@ static __always_inline void *slab_alloc(struct kmem_cache *s,
> >  	unsigned long flags;
> >  	unsigned int objsize;
> >
> > +	gfpflags &= slab_gfp_mask;
> > +
> >  	lockdep_trace_alloc(gfpflags);
> >  	might_sleep_if(gfpflags & __GFP_WAIT);
> >
> 
> Adds code to hot code path.
> 
> The allocators mask flags passed to the page allocator through
> GFP_RECLAIM_MASK|GFP_CONSTRAINT_MASK. This is done outside of the critical
> code paths.
> 
> The might_sleep issues may be fixed by adding another check to
> __might_sleep().

How about something like this? There should be no extra code in fastpaths 
for production configs with this one.

			Pekka

diff --git a/mm/slub.c b/mm/slub.c
index 4d6004c..5e8cea1 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1613,6 +1613,8 @@ another_slab:
 	deactivate_slab(s, c);
 
 new_slab:
+	gfpflags &= slab_gfp_mask;
+
 	new = get_partial(s, gfpflags, node);
 	if (new) {
 		c->page = new;
@@ -1668,13 +1670,14 @@ static __always_inline void *slab_alloc(struct kmem_cache *s,
 	struct kmem_cache_cpu *c;
 	unsigned long flags;
 	unsigned int objsize;
+	gfp_t real_gfp;
 
-	gfpflags &= slab_gfp_mask;
+	real_gfp = gfpflags & slab_gfp_mask;
 
-	lockdep_trace_alloc(gfpflags);
-	might_sleep_if(gfpflags & __GFP_WAIT);
+	lockdep_trace_alloc(real_gfp);
+	might_sleep_if(real_gfp & __GFP_WAIT);
 
-	if (should_failslab(s->objsize, gfpflags))
+	if (should_failslab(s->objsize, real_gfp))
 		return NULL;
 
 	local_irq_save(flags);
--
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/