Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752166AbaJOWcO (ORCPT ); Wed, 15 Oct 2014 18:32:14 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:37933 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751287AbaJOWcN (ORCPT ); Wed, 15 Oct 2014 18:32:13 -0400 Date: Wed, 15 Oct 2014 15:32:12 -0700 From: Andrew Morton To: Vlastimil Babka Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Minchan Kim , Mel Gorman , Joonsoo Kim , Michal Nazarewicz , Naoya Horiguchi , Christoph Lameter , Rik van Riel , David Rientjes Subject: Re: [PATCH 2/5] mm, compaction: simplify deferred compaction Message-Id: <20141015153212.7b9029c8bb8e9c1b8736181d@linux-foundation.org> In-Reply-To: <1412696019-21761-3-git-send-email-vbabka@suse.cz> References: <1412696019-21761-1-git-send-email-vbabka@suse.cz> <1412696019-21761-3-git-send-email-vbabka@suse.cz> X-Mailer: Sylpheed 3.2.0beta5 (GTK+ 2.24.10; 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 On Tue, 7 Oct 2014 17:33:36 +0200 Vlastimil Babka wrote: > Since commit ("mm, compaction: defer each zone individually instead of > preferred zone"), compaction is deferred for each zone where sync direct > compaction fails, and reset where it succeeds. However, it was observed > that for DMA zone compaction often appeared to succeed while subsequent > allocation attempt would not, due to different outcome of watermark check. > In order to properly defer compaction in this zone, the candidate zone has > to be passed back to __alloc_pages_direct_compact() and compaction deferred > in the zone after the allocation attempt fails. > > The large source of mismatch between watermark check in compaction and > allocation was the lack of alloc_flags and classzone_idx values in compaction, > which has been fixed in the previous patch. So with this problem fixed, we > can simplify the code by removing the candidate_zone parameter and deferring > in __alloc_pages_direct_compact(). > > After this patch, the compaction activity during stress-highalloc benchmark is > still somewhat increased, but it's negligible compared to the increase that > occurred without the better watermark checking. This suggests that it is still > possible to apparently succeed in compaction but fail to allocate, possibly > due to parallel allocation activity. > > ... > > --- a/include/linux/compaction.h > +++ b/include/linux/compaction.h > @@ -33,8 +33,7 @@ extern int fragmentation_index(struct zone *zone, unsigned int order); > extern unsigned long try_to_compact_pages(struct zonelist *zonelist, > int order, gfp_t gfp_mask, nodemask_t *mask, > enum migrate_mode mode, int *contended, > - int alloc_flags, int classzone_idx, > - struct zone **candidate_zone); > + int alloc_flags, int classzone_idx); > extern void compact_pgdat(pg_data_t *pgdat, int order); > extern void reset_isolation_suitable(pg_data_t *pgdat); > extern unsigned long compaction_suitable(struct zone *zone, int order, > @@ -105,8 +104,7 @@ static inline bool compaction_restarting(struct zone *zone, int order) > static inline unsigned long try_to_compact_pages(struct zonelist *zonelist, > int order, gfp_t gfp_mask, nodemask_t *nodemask, > enum migrate_mode mode, int *contended, > - int alloc_flags, int classzone_idx, > - struct zone **candidate_zone) > + int alloc_flags, int classzone_idx); > { > return COMPACT_CONTINUE; > } --- a/include/linux/compaction.h~mm-compaction-simplify-deferred-compaction-fix +++ a/include/linux/compaction.h @@ -104,7 +104,7 @@ static inline bool compaction_restarting static inline unsigned long try_to_compact_pages(struct zonelist *zonelist, int order, gfp_t gfp_mask, nodemask_t *nodemask, enum migrate_mode mode, int *contended, - int alloc_flags, int classzone_idx); + int alloc_flags, int classzone_idx) { return COMPACT_CONTINUE; } It clearly wasn't tested with this config. Please do so and let us know the result? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/