All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@suse.de>
To: Huang Shijie <b32955@freescale.com>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org, shijie8@gmail.com
Subject: Re: [PATCH v2] mm/compaction : check the watermark when cc->order is -1
Date: Fri, 13 Jan 2012 11:28:32 +0000	[thread overview]
Message-ID: <20120113112832.GR4118@suse.de> (raw)
In-Reply-To: <4F0F9770.10004@freescale.com>

On Fri, Jan 13, 2012 at 10:31:12AM +0800, Huang Shijie wrote:
> >>>  	/*
> >>>+	 * Watermarks for order-0 must be met for compaction.
> >>>+	 * During the migration, copies of pages need to be
> >>>+	 * allocated and for a short time, so the footprint is higher.
> >>>  	 * order == -1 is expected when compacting via
> >>>-	 * /proc/sys/vm/compact_memory
> >>>+	 * /proc/sys/vm/compact_memory.
> >>>  	 */
> >>>-	if (order == -1)
> >>>-		return COMPACT_CONTINUE;
> >>>+	watermark = low_wmark_pages(zone) +
> >>>+		((order == -1) ? (COMPACT_CLUSTER_MAX * 2) : (2UL<<  order));
> >>>
> >>>-	/*
> >>>-	 * Watermarks for order-0 must be met for compaction. Note the 2UL.
> >>>-	 * This is because during migration, copies of pages need to be
> >>>-	 * allocated and for a short time, the footprint is higher
> >>>-	 */
> >>>-	watermark = low_wmark_pages(zone) + (2UL<<  order);
> >>>  	if (!zone_watermark_ok(zone, 0, watermark, 0, 0))
> >>>  		return COMPACT_SKIPPED;
> >>>
> >>>+	if (order == -1)
> >>>+		return COMPACT_CONTINUE;
> >>>+
> >>>  	/*
> >>>  	 * fragmentation index determines if allocation failures are due to
> >>>  	 * low memory or external fragmentation
> >>Is this patch meaningless?
> >>I really think this patch is useful when the zone is nearly full.
> >>
> >Code wise the patch is fine. One reason why it fell off my radar is
> >because you mangled the comments for no apparent reason. Specifically,
> >after your patch is applied the code looks like this
> >
> >         /*
> >          * Watermarks for order-0 must be met for compaction.
> >          * During the migration, copies of pages need to be
> >          * allocated and for a short time, so the footprint is higher.
> >          * order == -1 is expected when compacting via
> >          * /proc/sys/vm/compact_memory.
> >          */
> >         watermark = low_wmark_pages(zone) +
> >                 ((order == -1) ? (COMPACT_CLUSTER_MAX * 2) : (2UL<<  order));
> "order == -1" first appears here.
> >         if (!zone_watermark_ok(zone, 0, watermark, 0, 0))
> >                 return COMPACT_SKIPPED;
> >
> >         if (order == -1)
> >                 return COMPACT_CONTINUE;
> >
> >The comment about "order == -1" is no longer with the code it refers
> If I keep the comment here, someone may wonder why the `order == -1`
> firstly appears above.
> 
> I just want to keep the comment where it firstly appears. Don't you
> think it's right?
> 

Bah, I'm an idiot.

When I glanced at this first, I missed that you altered the watermark
check as well. When I said "Code wise the patch is fine", I was wrong.
Compaction works in units of pageblocks and the watermark check
is necessary. Reducing it to COMPACT_CLUSTER_MAX*2 leads to the
possibility of compaction via /proc causing livelocks in low memory
situations depending on the value of min_free_kbytes.

-- 
Mel Gorman
SUSE Labs

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2012-01-13 11:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-06  2:50 [PATCH v2] mm/compaction : check the watermark when cc->order is -1 Huang Shijie
2012-01-12  5:59 ` Huang Shijie
2012-01-12 12:05   ` Mel Gorman
2012-01-13  2:31     ` Huang Shijie
2012-01-13 11:28       ` Mel Gorman [this message]
2012-01-14  2:10         ` Huang Shijie
2012-01-12  8:15 ` Minchan Kim
2012-01-12  8:31   ` Huang Shijie

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=20120113112832.GR4118@suse.de \
    --to=mgorman@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=b32955@freescale.com \
    --cc=linux-mm@kvack.org \
    --cc=shijie8@gmail.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.