From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758947AbcBXWPI (ORCPT ); Wed, 24 Feb 2016 17:15:08 -0500 Received: from mail-pf0-f179.google.com ([209.85.192.179]:36527 "EHLO mail-pf0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758415AbcBXWPG (ORCPT ); Wed, 24 Feb 2016 17:15:06 -0500 Date: Wed, 24 Feb 2016 14:15:03 -0800 (PST) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Rik van Riel cc: linux-kernel@vger.kernel.org, hannes@cmpxchg.org, akpm@linux-foundation.org, vbabka@suse.cz, mgorman@suse.de Subject: Re: [PATCH] mm: limit direct reclaim for higher order allocations In-Reply-To: <20160224163850.3d7eb56c@annuminas.surriel.com> Message-ID: References: <20160224163850.3d7eb56c@annuminas.surriel.com> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 24 Feb 2016, Rik van Riel wrote: > For multi page allocations smaller than PAGE_ALLOC_COSTLY_ORDER, > the kernel will do direct reclaim if compaction failed for any > reason. This worked fine when Linux systems had 128MB RAM, but > on my 24GB system I frequently see higher order allocations > free up over 3GB of memory, pushing all kinds of things into > swap, and slowing down applications. > Just curious, are these higher order allocations typically done by the slub allocator or where are they coming from? > It would be much better to limit the amount of reclaim done, > rather than cause excessive pageout activity. > > When enough memory is free to do compaction for the highest order > allocation possible, bail out of the direct page reclaim code. > > On smaller systems, this may be enough to obtain contiguous > free memory areas to satisfy small allocations, continuing our > strategy of relying on luck occasionally. On larger systems, > relying on luck like that has not been working for years. > > Signed-off-by: Rik van Riel > --- > mm/vmscan.c | 19 ++++++++----------- > 1 file changed, 8 insertions(+), 11 deletions(-) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index fc62546096f9..8dd15d514761 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -2584,20 +2584,17 @@ static bool shrink_zones(struct zonelist *zonelist, struct scan_control *sc) > continue; /* Let kswapd poll it */ > > /* > - * If we already have plenty of memory free for > - * compaction in this zone, don't free any more. > - * Even though compaction is invoked for any > - * non-zero order, only frequent costly order > - * reclamation is disruptive enough to become a > - * noticeable problem, like transparent huge > - * page allocations. > + * For higher order allocations, free enough memory > + * to be able to do compaction for the largest possible > + * allocation. On smaller systems, this may be enough > + * that smaller allocations can skip compaction, if > + * enough adjacent pages get freed. > */ > - if (IS_ENABLED(CONFIG_COMPACTION) && > - sc->order > PAGE_ALLOC_COSTLY_ORDER && > + if (IS_ENABLED(CONFIG_COMPACTION) && sc->order && > zonelist_zone_idx(z) <= requested_highidx && > - compaction_ready(zone, sc->order)) { > + compaction_ready(zone, MAX_ORDER)) { > sc->compaction_ready = true; > - continue; > + return true; > } > > /* >