On Sat, Jan 21, 2017 at 11:11:41AM +1100, NeilBrown wrote: > What are the benefits of GFP_TEMPORARY? Presumably it doesn't guarantee > success any more than GFP_KERNEL does, but maybe it is slightly less > likely to fail, and somewhat less likely to block for a long time?? But > without some sort of promise, I wonder why anyone would use the > flag. Is there a promise? Or is it just "you can be nice to the MM > layer by setting this flag sometimes". ??? My understanding is that the idea is to allow short-term use cases not to be mixed with long-term use cases --- in the Java world, to declare that a particular object will never be promoted from the "nursury" arena to the "tenured" arena, so that we don't end up with a situation where a page is used 90% for temporary objects, and 10% for a tenured object, such that later on we have a page which is 90% unused. Many of the existing users may in fact be for things like a temporary bounce buffer for I/O, where declaring this to the mm system could lead to less fragmented pages, but which would violate your proposed contract: > GFP_TEMPORARY should be used when the memory allocated will either be > freed, or will be placed in a reclaimable cache, before the process > which allocated it enters an TASK_INTERRUPTIBLE sleep or returns to > user-space. It allows access to memory which is usually reserved for > XXX and so can be expected to succeed more quickly during times of > high memory pressure. I think what you are suggested is something very different, where you are thinking that for *very* short-term usage perhaps we could have a pool of memory, perhaps the same as the GFP_ATOMIC memory, or at least similar in mechanism, where such usage could be handy. Is there enough use cases where this would be useful? In the local disk backed file system world, I doubt it. But maybe in the (for example) NFS world, such a use would in fact be common enough that it would be useful. I'd suggest doing this though as a new category, perhaps GFP_REALLY_SHORT_TERM, or GFP_MAYFLY for short. :-) - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
