All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: Rik van Riel <riel@redhat.com>
Cc: Johannes Hirte <johannes.hirte@fem.tu-ilmenau.de>,
	akpm@linux-foundation.org, mgorman@suse.de,
	Valdis.Kletnieks@vt.edu, jirislaby@gmail.com, jslaby@suse.cz,
	zkabelac@redhat.com, mm-commits@vger.kernel.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	torvalds@linux-foundation.org
Subject: Re: [PATCH] mm,vmscan: only loop back if compaction would fail in all zones
Date: Sun, 25 Nov 2012 22:15:18 -0500	[thread overview]
Message-ID: <20121126031518.GC2799@cmpxchg.org> (raw)
In-Reply-To: <20121125191645.0ebc6d59@annuminas.surriel.com>

On Sun, Nov 25, 2012 at 07:16:45PM -0500, Rik van Riel wrote:
> On Sun, 25 Nov 2012 17:44:33 -0500
> Johannes Weiner <hannes@cmpxchg.org> wrote:
> > On Sun, Nov 25, 2012 at 01:29:50PM -0500, Rik van Riel wrote:
> 
> > > Could you try this patch?
> > 
> > It's not quite enough because it's not reaching the conditions you
> > changed, see analysis in https://lkml.org/lkml/2012/11/20/567
> 
> Johannes,
> 
> does the patch below fix your problem?

I can not reproduce the problem anymore with my smoke test.

> I suspect it would, because kswapd should only ever run into this
> particular problem when we have a tiny memory zone in a pgdat,
> and in that case we will also have a larger zone nearby, where
> compaction would just succeed.

What if there is a higher order GFP_DMA allocation when the other
zones in the system meet the high watermark for this order?

There is something else that worries me: if the preliminary zone scan
finds the high watermark of all zones alright, end_zone is at its
initialization value, 0.  The final compaction loop at `if (order)'
goes through all zones up to and including end_zone, which was never
really set to anything meaningful(?) and the only zone considered is
the DMA zone again.  Very unlikely, granted, but if you'd ever hit
that race and kswapd gets stuck, this will be fun to debug...

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Johannes Weiner <hannes@cmpxchg.org>
To: Rik van Riel <riel@redhat.com>
Cc: Johannes Hirte <johannes.hirte@fem.tu-ilmenau.de>,
	akpm@linux-foundation.org, mgorman@suse.de,
	Valdis.Kletnieks@vt.edu, jirislaby@gmail.com, jslaby@suse.cz,
	zkabelac@redhat.com, mm-commits@vger.kernel.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	torvalds@linux-foundation.org
Subject: Re: [PATCH] mm,vmscan: only loop back if compaction would fail in all zones
Date: Sun, 25 Nov 2012 22:15:18 -0500	[thread overview]
Message-ID: <20121126031518.GC2799@cmpxchg.org> (raw)
In-Reply-To: <20121125191645.0ebc6d59@annuminas.surriel.com>

On Sun, Nov 25, 2012 at 07:16:45PM -0500, Rik van Riel wrote:
> On Sun, 25 Nov 2012 17:44:33 -0500
> Johannes Weiner <hannes@cmpxchg.org> wrote:
> > On Sun, Nov 25, 2012 at 01:29:50PM -0500, Rik van Riel wrote:
> 
> > > Could you try this patch?
> > 
> > It's not quite enough because it's not reaching the conditions you
> > changed, see analysis in https://lkml.org/lkml/2012/11/20/567
> 
> Johannes,
> 
> does the patch below fix your problem?

I can not reproduce the problem anymore with my smoke test.

> I suspect it would, because kswapd should only ever run into this
> particular problem when we have a tiny memory zone in a pgdat,
> and in that case we will also have a larger zone nearby, where
> compaction would just succeed.

What if there is a higher order GFP_DMA allocation when the other
zones in the system meet the high watermark for this order?

There is something else that worries me: if the preliminary zone scan
finds the high watermark of all zones alright, end_zone is at its
initialization value, 0.  The final compaction loop at `if (order)'
goes through all zones up to and including end_zone, which was never
really set to anything meaningful(?) and the only zone considered is
the DMA zone again.  Very unlikely, granted, but if you'd ever hit
that race and kswapd gets stuck, this will be fun to debug...

  reply	other threads:[~2012-11-26  3:16 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-19 20:21 [merged] mm-revert-mm-vmscan-scale-number-of-pages-reclaimed-by-reclaim-compaction-based-on-failures.patch removed from -mm tree akpm
     [not found] ` <20121125175728.3db4ac6a@fem.tu-ilmenau.de>
2012-11-25 18:29   ` [PATCH] mm,vmscan: free pages if compaction_suitable tells us to Rik van Riel
2012-11-25 22:44     ` Johannes Weiner
2012-11-25 22:44       ` Johannes Weiner
2012-11-25 23:31       ` Rik van Riel
2012-11-25 23:31         ` Rik van Riel
2012-11-26  0:16       ` [PATCH] mm,vmscan: only loop back if compaction would fail in all zones Rik van Riel
2012-11-26  0:16         ` Rik van Riel
2012-11-26  3:15         ` Johannes Weiner [this message]
2012-11-26  3:15           ` Johannes Weiner
2012-11-26  4:10           ` Johannes Weiner
2012-11-26  4:10             ` Johannes Weiner
2012-11-26 11:17             ` Johannes Hirte
2012-11-26 11:17               ` Johannes Hirte
2012-11-26 15:32             ` Rik van Riel
2012-11-26 15:32               ` Rik van Riel
2012-11-27 22:35             ` Valdis.Kletnieks
2012-11-26  1:21       ` [PATCH] mm,vmscan: free pages if compaction_suitable tells us to Jaegeuk Hanse
2012-11-26  1:21         ` Jaegeuk Hanse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121126031518.GC2799@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=akpm@linux-foundation.org \
    --cc=jirislaby@gmail.com \
    --cc=johannes.hirte@fem.tu-ilmenau.de \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mm-commits@vger.kernel.org \
    --cc=riel@redhat.com \
    --cc=torvalds@linux-foundation.org \
    --cc=zkabelac@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.