On Sun, Jan 22 2017, Theodore Ts'o wrote: > 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. :-) I'm not suggesting this particular contract is necessarily a good thing to have. I just suggested it as a possible definition of "GFP_TEMPORARY". If you are correct, then I was clearly wrong - which nicely serves to demonstrate that a clear definition is needed. You have used terms like "nursery" and "tenured" which don't really help without definitions of those terms. How about GFP_TEMPORARY should be used when the memory allocated will either be freed, or will be placed in a reclaimable cache, after some sequence of events which is time-limited. i.e. there must be no indefinite wait on the path from allocation to freeing-or-caching. The memory will typically be allocated from a region dedicated to GFP_TEMPORARY allocations, thus ensuring that this region does not become fragmented. Consequently, the delay imposed on GFP_TEMPORARY allocations is likely to be less than for non-TEMPORARY allocations when memory pressure is high. ?? I think that for this definition to work, we would need to make it "a movable cache", meaning that any item can be either freed or re-allocated (presumably to a "tenured" location). I don't think we currently have that concept for slabs do we? That implies that this flag would only apply to whole-page allocations (which was part of the original question). We could presumably add movability to slab-shrinkers if these seemed like a good idea. I think that it would also make sense to require that the path from allocation to freeing (or caching) of GFP_TEMPORARY allocation must not wait for a non-TEMPORARY allocation, as that becomes an indefinite wait. Is that any closer to your understanding? Thanks, NeilBrown
Attachment:
signature.asc
Description: PGP signature
