Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760775AbcDEX6a (ORCPT ); Tue, 5 Apr 2016 19:58:30 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:58743 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760532AbcDEX62 (ORCPT ); Tue, 5 Apr 2016 19:58:28 -0400 Date: Tue, 5 Apr 2016 16:58:26 -0700 From: Andrew Morton To: Michal Hocko Cc: Linus Torvalds , Johannes Weiner , Mel Gorman , David Rientjes , Tetsuo Handa , Joonsoo Kim , Hillf Danton , , LKML , Michal Hocko , Hugh Dickins Subject: Re: [PATCH 09/11] mm, compaction: Abstract compaction feedback to helpers Message-Id: <20160405165826.012236e79db7f396fda546a8@linux-foundation.org> In-Reply-To: <1459855533-4600-10-git-send-email-mhocko@kernel.org> References: <1459855533-4600-1-git-send-email-mhocko@kernel.org> <1459855533-4600-10-git-send-email-mhocko@kernel.org> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2488 Lines: 72 On Tue, 5 Apr 2016 13:25:31 +0200 Michal Hocko wrote: > 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. > > ... > > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -3362,25 +3362,12 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, > if (page) > goto got_pg; > > - /* Checks for THP-specific high-order allocations */ > - if (is_thp_gfp_mask(gfp_mask)) { > - /* > - * 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 (compact_result == COMPACT_DEFERRED) > - goto nopage; > - > - /* > - * Compaction is contended so rather back off than cause > - * excessive stalls. > - */ > - if(compact_result == COMPACT_CONTENDED) > - goto nopage; > - } > + /* > + * Checks for THP-specific high-order allocations and back off > + * if the the compaction backed off > + */ > + if (is_thp_gfp_mask(gfp_mask) && compaction_withdrawn(compact_result)) > + goto nopage; This change smashed into Hugh's "huge tmpfs: shmem_huge_gfpmask and shmem_recovery_gfpmask". I ended up doing this: /* Checks for THP-specific high-order allocations */ if (!is_thp_allocation(gfp_mask, order)) migration_mode = MIGRATE_SYNC_LIGHT; /* * Checks for THP-specific high-order allocations and back off * if the the compaction backed off */ if (is_thp_allocation(gfp_mask) && compaction_withdrawn(compact_result)) goto nopage;