Re: [ATTEND] many topics

[NeilBrown <neilb@suse.com>]

[-- Attachment #1: Type: text/plain, Size: 5049 bytes --]

On Mon, Jan 23 2017, Matthew Wilcox wrote:

> On Sun, Jan 22, 2017 at 03:45:01PM +1100, NeilBrown wrote:
>> 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:
>
> I don't have a clear picture in my mind of when Java promotes objects
> from nursery to tenure ... which is not too different from my lack of
> understanding of what the MM layer considers "temporary" :-)  Is it
> acceptable usage to allocate a SCSI command (guaranteed to be freed
> within 30 seconds) from the temporary area?  Or should it only be used
> for allocations where the thread of control is not going to sleep between
> allocation and freeing?
>
>> 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 you're overcomplicating your proposed contract by allowing for
> the "adding to a reclaimable cache" case.  If that will happen, the
> code should be using GFP_RECLAIMABLE, not GFP_TEMPORARY as a matter of
> good documentation.  And to allow the definitions to differ in future.
> Maybe they will always be the same bit pattern, but the code should
> distinguish the two cases (obviously there is no problem with allocating
> memory with GFP_RECLAIMABLE, then deciding you didn't need it after all
> and freeing it).

I only included the "Reclaimable cache" possibility because Michal said:

   I guess the original intention was to use this flag for allocations
   which will be either freed shortly or they are reclaimable.


>
>> ??
>> 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.
>
> Funnily, Christoph Lameter and I are working on just such a proposal.
> He put it up as a topic discussion at the LCA Kernel Miniconf, and I've
> done a proof of concept implementation for radix tree nodes.  It needs
> changes to the radix tree API to make it work, so it's not published yet,
> but it's a useful proof of concept for things which can probably work
> and be more effective, like the dentry & inode caches.

Awesome!

>
>> 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.
>
> ... can it even wait for *another* TEMPORARY allocation?  I really think
> this discussion needs to take place in a room with more people present
> so we can get misunderstandings hammered out and general acceptance of
> the consensus.

I suspect you are right, but throwing around some thoughts in advance,
to spark new ideas, can't hurt?  I hate going to meetings where the
agenda has a topic, but no background discussion.  It means that I have
to do all my thinking on my feet (not that I'll be at this meeting).

NeilBrown


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]