On Mon, 18 Jul 2016, Vlastimil Babka wrote: > Since THP allocations during page faults can be costly, extra decisions are > employed for them to avoid excessive reclaim and compaction, if the initial > compaction doesn't look promising. The detection has never been perfect as > there is no gfp flag specific to THP allocations. At this moment it checks the > whole combination of flags that makes up GFP_TRANSHUGE, and hopes that no other > users of such combination exist, or would mind being treated the same way. > Extra care is also taken to separate allocations from khugepaged, where latency > doesn't matter that much. > > It is however possible to distinguish these allocations in a simpler and more > reliable way. The key observation is that after the initial compaction followed > by the first iteration of "standard" reclaim/compaction, both __GFP_NORETRY > allocations and costly allocations without __GFP_REPEAT are declared as > failures: > > /* Do not loop if specifically requested */ > if (gfp_mask & __GFP_NORETRY) > goto nopage; > > /* > * Do not retry costly high order allocations unless they are > * __GFP_REPEAT > */ > if (order > PAGE_ALLOC_COSTLY_ORDER && !(gfp_mask & __GFP_REPEAT)) > goto nopage; > > This means we can further distinguish allocations that are costly order *and* > additionally include the __GFP_NORETRY flag. As it happens, GFP_TRANSHUGE > allocations do already fall into this category. This will also allow other > costly allocations with similar high-order benefit vs latency considerations to > use this semantic. Furthermore, we can distinguish THP allocations that should > try a bit harder (such as from khugepageed) by removing __GFP_NORETRY, as will > be done in the next patch. > > Signed-off-by: Vlastimil Babka <vbabka@xxxxxxx> > Acked-by: Michal Hocko <mhocko@xxxxxxxx> I think this is fine, but I would hope that we could check gfp_pfmemalloc_allowed() before compacting and failing even for costly orders when otherwise the first get_page_from_freelist() in the slowpath may have succeeded due to watermarks. -- 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>