Re: [PATCH 4/8] mm, page_alloc: restructure direct compaction handling in slowpath

2016-07-20 Thread Vlastimil Babka
On 07/20/2016 12:50 AM, David Rientjes wrote: > On Mon, 18 Jul 2016, Vlastimil Babka wrote: > >> diff --git a/mm/page_alloc.c b/mm/page_alloc.c >> index 30443804f156..a04a67745927 100644 >> --- a/mm/page_alloc.c >> +++ b/mm/page_alloc.c >> @@ -3510,7 +3510,7 @@ __alloc_pages_slowpath(gfp_t gfp_mas

Re: [PATCH 4/8] mm, page_alloc: restructure direct compaction handling in slowpath

2016-07-19 Thread David Rientjes
On Mon, 18 Jul 2016, Vlastimil Babka wrote: > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 30443804f156..a04a67745927 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -3510,7 +3510,7 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int > order, > struct page *page = N

[PATCH 4/8] mm, page_alloc: restructure direct compaction handling in slowpath

2016-07-18 Thread Vlastimil Babka
The retry loop in __alloc_pages_slowpath is supposed to keep trying reclaim and compaction (and OOM), until either the allocation succeeds, or returns with failure. Success here is more probable when reclaim precedes compaction, as certain watermarks have to be met for compaction to even try, and m