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