Messages in this thread | | | Date | Tue, 19 Jul 2016 16:10:31 -0700 (PDT) | From | David Rientjes <> | Subject | Re: [PATCH 5/8] mm, page_alloc: make THP-specific decisions more generic |
| |
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@suse.cz> > Acked-by: Michal Hocko <mhocko@suse.com>
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.
| |