From: Rik van Riel <riel@redhat.com>
To: Vlastimil Babka <vbabka@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Minchan Kim <minchan@kernel.org>, Mel Gorman <mgorman@suse.de>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Michal Nazarewicz <mina86@mina86.com>,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
Christoph Lameter <cl@linux.com>,
David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 5/5] mm, compaction: more focused lru and pcplists draining
Date: Mon, 20 Oct 2014 11:44:18 -0400 [thread overview]
Message-ID: <54452DD2.8090205@redhat.com> (raw)
In-Reply-To: <1412696019-21761-6-git-send-email-vbabka@suse.cz>
On 10/07/2014 11:33 AM, Vlastimil Babka wrote:
> The goal of memory compaction is to create high-order freepages through page
> migration. Page migration however puts pages on the per-cpu lru_add cache,
> which is later flushed to per-cpu pcplists, and only after pcplists are
> drained the pages can actually merge. This can happen due to the per-cpu
> caches becoming full through further freeing, or explicitly.
>
> During direct compaction, it is useful to do the draining explicitly so that
> pages merge as soon as possible and compaction can detect success immediately
> and keep the latency impact at minimum. However the current implementation is
> far from ideal. Draining is done only in __alloc_pages_direct_compact(),
> after all zones were already compacted, and the decisions to continue or stop
> compaction in individual zones was done without the last batch of migrations
> being merged. It is also missing the draining of lru_add cache before the
> pcplists.
>
> This patch moves the draining for direct compaction into compact_zone(). It
> adds the missing lru_cache draining and uses the newly introduced single zone
> pcplists draining to reduce overhead and avoid impact on unrelated zones.
> Draining is only performed when it can actually lead to merging of a page of
> desired order (passed by cc->order). This means it is only done when migration
> occurred in the previously scanned cc->order aligned block(s) and the
> migration scanner is now pointing to the next cc->order aligned block.
Acked-by: Rik van Riel <riel@redhat.com>
--
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: Rik van Riel <riel@redhat.com>
To: Vlastimil Babka <vbabka@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Minchan Kim <minchan@kernel.org>, Mel Gorman <mgorman@suse.de>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Michal Nazarewicz <mina86@mina86.com>,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
Christoph Lameter <cl@linux.com>,
David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 5/5] mm, compaction: more focused lru and pcplists draining
Date: Mon, 20 Oct 2014 11:44:18 -0400 [thread overview]
Message-ID: <54452DD2.8090205@redhat.com> (raw)
In-Reply-To: <1412696019-21761-6-git-send-email-vbabka@suse.cz>
On 10/07/2014 11:33 AM, Vlastimil Babka wrote:
> The goal of memory compaction is to create high-order freepages through page
> migration. Page migration however puts pages on the per-cpu lru_add cache,
> which is later flushed to per-cpu pcplists, and only after pcplists are
> drained the pages can actually merge. This can happen due to the per-cpu
> caches becoming full through further freeing, or explicitly.
>
> During direct compaction, it is useful to do the draining explicitly so that
> pages merge as soon as possible and compaction can detect success immediately
> and keep the latency impact at minimum. However the current implementation is
> far from ideal. Draining is done only in __alloc_pages_direct_compact(),
> after all zones were already compacted, and the decisions to continue or stop
> compaction in individual zones was done without the last batch of migrations
> being merged. It is also missing the draining of lru_add cache before the
> pcplists.
>
> This patch moves the draining for direct compaction into compact_zone(). It
> adds the missing lru_cache draining and uses the newly introduced single zone
> pcplists draining to reduce overhead and avoid impact on unrelated zones.
> Draining is only performed when it can actually lead to merging of a page of
> desired order (passed by cc->order). This means it is only done when migration
> occurred in the previously scanned cc->order aligned block(s) and the
> migration scanner is now pointing to the next cc->order aligned block.
Acked-by: Rik van Riel <riel@redhat.com>
next prev parent reply other threads:[~2014-10-20 15:44 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-07 15:33 [PATCH 0/5] Further compaction tuning Vlastimil Babka
2014-10-07 15:33 ` Vlastimil Babka
2014-10-07 15:33 ` [PATCH 1/5] mm, compaction: pass classzone_idx and alloc_flags to watermark checking Vlastimil Babka
2014-10-07 15:33 ` Vlastimil Babka
2014-10-20 15:45 ` Rik van Riel
2014-10-20 15:45 ` Rik van Riel
2014-10-27 6:46 ` Joonsoo Kim
2014-10-27 6:46 ` Joonsoo Kim
2014-10-27 9:11 ` Vlastimil Babka
2014-10-27 9:11 ` Vlastimil Babka
2014-10-28 7:16 ` Joonsoo Kim
2014-10-28 7:16 ` Joonsoo Kim
2014-10-29 13:51 ` Vlastimil Babka
2014-10-29 13:51 ` Vlastimil Babka
2014-10-31 7:49 ` Joonsoo Kim
2014-10-31 7:49 ` Joonsoo Kim
2014-11-14 8:52 ` Vlastimil Babka
2014-11-14 8:52 ` Vlastimil Babka
2014-10-07 15:33 ` [PATCH 2/5] mm, compaction: simplify deferred compaction Vlastimil Babka
2014-10-07 15:33 ` Vlastimil Babka
2014-10-15 22:32 ` Andrew Morton
2014-10-15 22:32 ` Andrew Morton
2014-10-16 15:11 ` Vlastimil Babka
2014-10-16 15:11 ` Vlastimil Babka
2014-10-07 15:33 ` [PATCH 3/5] mm, compaction: defer only on COMPACT_COMPLETE Vlastimil Babka
2014-10-07 15:33 ` Vlastimil Babka
2014-10-20 15:18 ` Rik van Riel
2014-10-20 15:18 ` Rik van Riel
2014-10-07 15:33 ` [PATCH 4/5] mm, compaction: always update cached scanner positions Vlastimil Babka
2014-10-07 15:33 ` Vlastimil Babka
2014-10-20 15:26 ` Rik van Riel
2014-10-20 15:26 ` Rik van Riel
2014-10-27 7:35 ` Joonsoo Kim
2014-10-27 7:35 ` Joonsoo Kim
2014-10-27 9:39 ` Vlastimil Babka
2014-10-27 9:39 ` Vlastimil Babka
2014-10-28 7:08 ` Joonsoo Kim
2014-10-28 7:08 ` Joonsoo Kim
2014-10-31 15:53 ` Vlastimil Babka
2014-10-31 15:53 ` Vlastimil Babka
2014-11-04 0:28 ` Joonsoo Kim
2014-11-04 0:28 ` Joonsoo Kim
2014-11-14 8:57 ` Vlastimil Babka
2014-11-14 8:57 ` Vlastimil Babka
2014-10-07 15:33 ` [PATCH 5/5] mm, compaction: more focused lru and pcplists draining Vlastimil Babka
2014-10-07 15:33 ` Vlastimil Babka
2014-10-20 15:44 ` Rik van Riel [this message]
2014-10-20 15:44 ` Rik van Riel
2014-10-27 7:41 ` Joonsoo Kim
2014-10-27 7:41 ` Joonsoo Kim
2014-11-03 8:12 ` Vlastimil Babka
2014-11-03 8:12 ` Vlastimil Babka
2014-11-04 0:37 ` Joonsoo Kim
2014-11-04 0:37 ` Joonsoo Kim
2014-11-13 12:47 ` Vlastimil Babka
2014-11-13 12:47 ` Vlastimil Babka
2014-11-14 7:05 ` Joonsoo Kim
2014-11-14 7:05 ` Joonsoo Kim
2014-11-19 22:53 ` Vlastimil Babka
2014-11-19 22:53 ` Vlastimil Babka
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=54452DD2.8090205@redhat.com \
--to=riel@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mina86@mina86.com \
--cc=minchan@kernel.org \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=rientjes@google.com \
--cc=vbabka@suse.cz \
/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.