Messages in this thread | | | Date | Mon, 14 Aug 2006 13:42:20 +1000 | From | Nick Piggin <> | Subject | Re: rename *MEMALLOC flags |
| |
Paul Jackson wrote: > Daniel wrote: > >>Inventing a new name for an existing thing is very poor taste on grounds of >>grepability alone. > > > I wouldn't say 'very poor taste' -- just something that should be > done infrequently, with good reason, and with reasonable concensus, > especially from the key maintainers in the affected area. > > Good names are good taste, in my book. But stable naming is good too. > > I wonder what Nick thinks of this? Looks like he added > __GFP_NOMEMALLOC a year ago, following the naming style of PF_MEMALLOC. > > I added him to the cc list. >
__GFP_NOMEMALLOC was added to prevent mempool backed allocations from accessing the emergency reserve. Because that would just shift deadlocks from mempool "safe" sites to those which have not been converted.
PF_MEMALLOC is a good name: PF_MEMALLOC says that the task is currently allocating memory. It does not say anything about the actual allocator implementation details to handle this (1. don't recurse into reclaim; 2. allow access to reserves), but that is a good thing.
__GFP_NOMEMALLOC and __GFP_MEMALLOC are poorly named (I take the blame). It isn't that the task is suddenly no longer allocating in the context of an allocation, it is just that you want to allow or deny access to the reserve.
__GFP_NOMEMALLOC should be something like __GFP_EMERG_NEVER and __GFP_MEMALLOC should be _ALWAYS. Or something like that.
NOMEMALLOC is specific enough that I don't mind a rename at this stage. Renaming PF_MEMALLOC would be wrong, however.
-- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com
- 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/
| |