On Sun, 28 Oct 2012 21:22:15 +0000 Mel Gorman <mgorman@xxxxxxx> wrote: > > Hi, this one breaks UML build: > > In function ???is_thp_alloc???, > > inlined from ???__alloc_pages_slowpath??? at mm/page_alloc.c:2427:20, > > inlined from ???__alloc_pages_nodemask??? at mm/page_alloc.c:2645:8: > > mm/page_alloc.c:2383:15: error: call to ???__build_bug_failed??? declared > > with attribute error: BUILD_BUG failed > > > > That arch does not support THP. > > > > ---8<--- > mm: page_alloc: Do not wake kswapd if the request is for THP but deferred > > Since commit c6543459 (mm: remove __GFP_NO_KSWAPD), kswapd gets woken > for every THP request in the slow path. If compaction has been deferred > the waker will not compact or enter direct reclaim on its own behalf > but kswapd is still woken to reclaim free pages that no one may consume. > If compaction was deferred because pages and slab was not reclaimable > then kswapd is just consuming cycles for no gain. > > This patch avoids waking kswapd if the compaction has been deferred. > It'll still wake when compaction is running to reduce the latency of > THP allocations. umwhat? I'd struggling to see how this patch will fix the UML build. > index bb90971..e72674c 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -2378,6 +2378,15 @@ bool gfp_pfmemalloc_allowed(gfp_t gfp_mask) > return !!(gfp_to_alloc_flags(gfp_mask) & ALLOC_NO_WATERMARKS); > } > > +/* Returns true if the allocation is likely for THP */ Comment is a bit awkward/ambiguous. Perhaps "if this allocation is probably asking for a THP hugepage". And why the "likely"/"probably"? Is it so hard to know for certain? Anyway, I think I'll duck this patch under the assumption you pasted the wrong thing into that email. I currently have mm-vmscan-scale-number-of-pages-reclaimed-by-reclaim-compaction-only-in-direct-reclaim.patch queued for 3.7, but on hold due to Valdis's bug report. -- To unsubscribe from this list: send the line "unsubscribe mm-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
