Re: Propagating GFP_NOFS inside __vmalloc()

["Ricardo M. Correia" <ricardo.correia@oracle.com>]

On Thu, 2010-11-11 at 23:45 +0100, Ricardo M. Correia wrote:
> On Thu, 2010-11-11 at 14:25 -0800, Andrew Morton wrote:
> > And then we can set current->gfp_mask to GFP_ATOMIC when we take an
> > interrupt, or take a spinlock.

Also, doesn't this mean that spin_lock() would now have to save
current->gfp_flags in the stack?

So that we can restore the allocation mode when we do spin_unlock()?

- Ricardo

> > 
> > And leave it at GFP_KERNEL when in process context.
> > 
> > And switch GFP_KERNEL to GFP_NOFS in the VM.
> > 
> > And switch to GFP_NOIO in the block layer.
> > 
> > So the allocation mode becomes implicit to the task state, so callers
> > usually don't need to track it.
> > 
> > So, ultimately, kmalloc(), alloc_pages() etc don't actually need a mode
> > arg at all.  We'll need new, special functions which _do_ take the
> > gfp_t but they will be rarely-called specialised things.
> >
> > And probably we'll need interfaces like
> > 
> > 	gfp_t mm_set_alloc_mode(gfp_t flags);
> > 	void mm_restore_alloc_mode(gfp_t flags);
> > 
> > 	gfp_t flags;
> > 
> > 	flags = mm_set_alloc_mode(GFP_NOIO);
> > 	...
> > 	mm_restore_alloc_mode(flags);
> 
> Actually, I think it may not be that simple...
> 
> Looking at some of the __GFP_* flags, it seems that some of them look
> like allocation "options", i.e. something we may want or may not want to
> do on a certain allocation, others look more like "capabilities", i.e.
> something that we can or cannot do in a certain context.
> 
> For example, __GFP_ZERO, __GFP_REPEAT, __GFP_HIGHMEM, ... is something
> that we'd probably want a caller to specify on each allocation, because
> only he knows what he actually wants to do.
> 
> Others, like __GFP_FS, __GFP_IO, __GFP_WAIT, are things that we either
> can or cannot do, depending on the context that we're in.
> 
> The latter ones seem worth to start tracking on the task_struct, but the
> former ones I think we'd still want to pass them to kmalloc() on each
> invocation.
> 
> Fortunately, if we put the latter ones in the task_struct, it removes
> the need for having to propagate gfp_flags from function to function.
> 
> And contrary to what you said previously (which at the time sounded
> correct to me), this can actually save a lot of stack space, especially
> on more register-starved architectures, because the only places where we
> need to save the flags on the stack is when we enter/exit a certain
> context, as opposed to having to always having to pass the gfp_mask down
> the call stack like we do now.
> 
> > argh, someone save us.
> 
> :-)
> 
> Thanks,
> Ricardo
> 


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>