Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751829AbcDUG6A (ORCPT ); Thu, 21 Apr 2016 02:58:00 -0400 Received: from out4440.biz.mail.alibaba.com ([47.88.44.40]:63507 "EHLO out4440.biz.mail.alibaba.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751237AbcDUG56 (ORCPT ); Thu, 21 Apr 2016 02:57:58 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R161e4;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e02c03284;MF=hillf.zj@alibaba-inc.com;NM=1;PH=DS;RN=12;SR=0;TI=SMTPD_----4j0NgvG_1461221833; Reply-To: "Hillf Danton" From: "Hillf Danton" To: "'Michal Hocko'" , "'Andrew Morton'" Cc: "'Linus Torvalds'" , "'Johannes Weiner'" , "'Mel Gorman'" , "'David Rientjes'" , "'Tetsuo Handa'" , "'Joonsoo Kim'" , "'Vlastimil Babka'" , , "'LKML'" , "'Michal Hocko'" References: <1461181647-8039-1-git-send-email-mhocko@kernel.org> <1461181647-8039-9-git-send-email-mhocko@kernel.org> In-Reply-To: <1461181647-8039-9-git-send-email-mhocko@kernel.org> Subject: Re: [PATCH 08/14] mm, compaction: Abstract compaction feedback to helpers Date: Thu, 21 Apr 2016 14:57:13 +0800 Message-ID: <02d001d19b9b$092f8380$1b8e8a80$@alibaba-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG1HgS+iScJ1ld6BkmHPkLx52RrNAIFnLMJn7zMeAA= Content-Language: zh-cn Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4167 Lines: 131 > > From: Michal Hocko > > Compaction can provide a wild variation of feedback to the caller. Many > of them are implementation specific and the caller of the compaction > (especially the page allocator) shouldn't be bound to specifics of the > current implementation. > > This patch abstracts the feedback into three basic types: > - compaction_made_progress - compaction was active and made some > progress. > - compaction_failed - compaction failed and further attempts to > invoke it would most probably fail and therefore it is not > worth retrying > - compaction_withdrawn - compaction wasn't invoked for an > implementation specific reasons. In the current implementation > it means that the compaction was deferred, contended or the > page scanners met too early without any progress. Retrying is > still worthwhile. > > [vbabka@suse.cz: do not change thp back off behavior] > Signed-off-by: Michal Hocko > --- Acked-by: Hillf Danton > include/linux/compaction.h | 79 ++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 79 insertions(+) > > diff --git a/include/linux/compaction.h b/include/linux/compaction.h > index a7b9091ff349..a002ca55c513 100644 > --- a/include/linux/compaction.h > +++ b/include/linux/compaction.h > @@ -78,6 +78,70 @@ extern void compaction_defer_reset(struct zone *zone, int order, > bool alloc_success); > extern bool compaction_restarting(struct zone *zone, int order); > > +/* Compaction has made some progress and retrying makes sense */ > +static inline bool compaction_made_progress(enum compact_result result) > +{ > + /* > + * Even though this might sound confusing this in fact tells us > + * that the compaction successfully isolated and migrated some > + * pageblocks. > + */ > + if (result == COMPACT_PARTIAL) > + return true; > + > + return false; > +} > + > +/* Compaction has failed and it doesn't make much sense to keep retrying. */ > +static inline bool compaction_failed(enum compact_result result) > +{ > + /* All zones where scanned completely and still not result. */ s/where/were/ > + if (result == COMPACT_COMPLETE) > + return true; > + > + return false; > +} > + > +/* > + * Compaction has backed off for some reason. It might be throttling or > + * lock contention. Retrying is still worthwhile. > + */ > +static inline bool compaction_withdrawn(enum compact_result result) > +{ > + /* > + * Compaction backed off due to watermark checks for order-0 > + * so the regular reclaim has to try harder and reclaim something. > + */ > + if (result == COMPACT_SKIPPED) > + return true; > + > + /* > + * If compaction is deferred for high-order allocations, it is > + * because sync compaction recently failed. If this is the case > + * and the caller requested a THP allocation, we do not want > + * to heavily disrupt the system, so we fail the allocation > + * instead of entering direct reclaim. > + */ > + if (result == COMPACT_DEFERRED) > + return true; > + > + /* > + * If compaction in async mode encounters contention or blocks higher > + * priority task we back off early rather than cause stalls. > + */ > + if (result == COMPACT_CONTENDED) > + return true; > + > + /* > + * Page scanners have met but we haven't scanned full zones so this > + * is a back off in fact. > + */ > + if (result == COMPACT_PARTIAL_SKIPPED) > + return true; > + > + return false; > +} > + > extern int kcompactd_run(int nid); > extern void kcompactd_stop(int nid); > extern void wakeup_kcompactd(pg_data_t *pgdat, int order, int classzone_idx); > @@ -114,6 +178,21 @@ static inline bool compaction_deferred(struct zone *zone, int order) > return true; > } > > +static inline bool compaction_made_progress(enum compact_result result) > +{ > + return false; > +} > + > +static inline bool compaction_failed(enum compact_result result) > +{ > + return false; > +} > + > +static inline bool compaction_withdrawn(enum compact_result result) > +{ > + return true; > +} > + > static inline int kcompactd_run(int nid) > { > return 0; > -- > 2.8.0.rc3