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@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
