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. > > 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@xxxxxxxxxx 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@xxxxxxxxx";> email@xxxxxxxxx </a>