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.
- GFP_TEMPORARY allocations may be held on to for a considerable length
of time; certainly seconds and maybe minutes.
- 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.
- Other higher-order allocations are more likely to succeed due to
the segregation of short and long lived allocations from each other.
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 ...)
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 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
