Re: [ATTEND] many topics

[Vlastimil Babka <vbabka@suse.cz>]

On 01/25/2017 09:36 PM, Matthew Wilcox wrote:
> On Wed, Jan 25, 2017 at 03:36:15PM +0100, Vlastimil Babka wrote:
>> On 01/23/2017 08:34 PM, NeilBrown wrote:
>> > Because "TEMPORARY" implies a limit to the amount of time, and sleeping
>> > is the thing that causes a process to take a large amount of time.  It
>> > seems like an obvious connection to me.
>>
>> There's no simple connection to time, it depends on the larger picture -
>> what's the state of the allocator and what other allocations/free's are
>> happening around this one. Perhaps let me try to explain what the flag does
>> and what benefits are expected.
>
> The explanations of what GFP_TEMPORARY /does/ keep getting better and
> better.  And thank you for that, it really is interesting.  But what
> we're asking for is guidelines for the user of this interface; what is
> the contract between the caller and the MM system?
>
> So far, I think we've answered a few questions:
>
>  - Using GFP_TEMPORARY in calls to kmalloc() is not currently supported
>    because slab will happily allocate non-TEMPORARY allocations from the
>    same page.

Sounds right, AFAIK there's no smarts in slab about this.

>  - GFP_TEMPORARY allocations may be held on to for a considerable length
>    of time; certainly seconds and maybe minutes.

I'd agree.

>  - The advantage of marking one's allocation as TEMPORARY is twofold:
>    - This allocation is more likely to succeed due to being allowed to
>      access more memory.

There's no such provision in the current implementation.

>    - Other higher-order allocations are more likely to succeed due to
>      the segregation of short and long lived allocations from each other.

Right.

> I'd like to see us add a tmalloc() / tmalloc_atomic() / tfree() API
> for allocating temporary memory, then hook that up to SLAB as a way to
> allocate small amounts of memory (... although maybe we shouldn't try
> too hard to allocate multiple objects from a single page if they're all
> temporary ...)

Before doing things like that, we should evaluate whether the benefits are 
really worth it. I only know how the mobility grouping and related heuristics 
work, but haven't measured or seen some results wrt GFP_TEMPORARY. Also are 
there some large potential users you have in mind? If there's always some 
constant small amount of temporary allocations in the system, then the benefits 
should be rather small as that amount will be effectively non-defragmentable in 
any given point of time. I would expect the most benefit when there are some 
less frequent but large bursts of temporary allocations concurrently with 
long-term unmovable allocations that will result in permanently polluting new 
pageblocks.

> In any case, we need to ensure that GFP_TEMPORARY is not accepted by
> slab ... that's not as straightforward as adding __GFP_RECLAIMABLE to
> GFP_SLAB_BUG_MASK because SLAB_RECLAIMABLE slabs will reasonable add
> __GFP_RECLAIMABLE before the check.  So a good place to check it is ...
> kmalloc_slab()?  That hits all three slab allocators.
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>