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, 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>