All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Mel Gorman <mgorman@suse.de>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	linux-mm@kvack.org, Minchan Kim <minchan@kernel.org>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Kyungmin Park <kyungmin.park@samsung.com>
Subject: Re: [PATCH v3] mm: compaction: handle incorrect Unmovable type pageblocks
Date: Thu, 26 Apr 2012 14:52:56 -0400	[thread overview]
Message-ID: <4F999988.802@redhat.com> (raw)
In-Reply-To: <20120426164713.GG15299@suse.de>

On 04/26/2012 12:47 PM, Mel Gorman wrote:

> Instead of COMPACT_ASYNC_PARTIAL and COMPACT_ASYNC_FULL should we have
> COMPACT_ASYNC_MOVABLE and COMPACT_ASYNC_UNMOVABLE? The first pass from
> the page allocator (COMPACT_ASYNC_MOVABLE) would only consider MOVABLE
> blocks as migration targets. The second pass (COMPACT_ASYNC_UNMOVABLE)
> would examine UNMOVABLE blocks, rescue them and use what blocks it
> rescues as migration targets. The third pass (COMPACT_SYNC) would work
> as it does currently. kswapd would only ever use COMPACT_ASYNC_MOVABLE.
>
> That would avoid rescanning the movable blocks uselessly on the second
> pass but should still work for Bartlomiej's workload.
>
> What do you think?

This makes sense.

>> In other words, could it be better to always try to
>> rescue the unmovable blocks?
>
> I do not think we should always scan within unmovable blocks on the
> first pass. I strongly suspect it would lead to excessive amounts of CPU
> time spent in mm/compaction.c.

Maybe my systems are not typical.  I have not seen
more than about 10% of the memory blocks marked as
unmovable in my system.

--
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-04-26 18:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-26  8:15 [PATCH v3] mm: compaction: handle incorrect Unmovable type pageblocks Bartlomiej Zolnierkiewicz
2012-04-26 14:36 ` Mel Gorman
2012-04-26 15:53   ` Rik van Riel
2012-04-26 16:47     ` Mel Gorman
2012-04-26 18:52       ` Rik van Riel [this message]
2012-04-27  9:45         ` Mel Gorman
2012-04-27  0:58       ` Minchan Kim
2012-04-27  9:56         ` Mel Gorman
2012-04-30  2:44           ` Minchan Kim
2012-04-30  8:31             ` Mel Gorman
2012-04-30  8:55               ` Minchan Kim
2012-04-30  9:16                 ` Mel Gorman
2012-04-26 15:42 ` Rik van Riel

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=4F999988.802@redhat.com \
    --to=riel@redhat.com \
    --cc=b.zolnierkie@samsung.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-mm@kvack.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mgorman@suse.de \
    --cc=minchan@kernel.org \
    /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.