From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: akpm@linux-foundation.org, mgorman@suse.de,
matthew.garrett@nebula.com, dave@sr71.net, rientjes@google.com,
riel@redhat.com, arjan@linux.intel.com,
srinivas.pandruvada@linux.intel.com,
maxime.coquelin@stericsson.com, loic.pallardy@stericsson.com,
kamezawa.hiroyu@jp.fujitsu.com, lenb@kernel.org, rjw@sisk.pl
Cc: gargankita@gmail.com, paulmck@linux.vnet.ibm.com,
amit.kachhap@linaro.org, svaidy@linux.vnet.ibm.com,
andi@firstfloor.org, wujianguo@huawei.com, kmpark@infradead.org,
thomas.abraham@linaro.org, santosh.shilimkar@ti.com,
srivatsa.bhat@linux.vnet.ibm.com, linux-pm@vger.kernel.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: [RFC PATCH v2 14/15] mm: Add alloc-free handshake to trigger memory region compaction
Date: Wed, 10 Apr 2013 03:18:56 +0530 [thread overview]
Message-ID: <20130409214853.4500.63619.stgit@srivatsabhat.in.ibm.com> (raw)
In-Reply-To: <20130409214443.4500.44168.stgit@srivatsabhat.in.ibm.com>
We need a way to decide when to trigger the worker threads to perform
region evacuation/compaction. So the strategy used is as follows:
Alloc path of page allocator:
----------------------------
This accurately tracks the allocations and detects the first allocation
in a new region and notes down that region number. Performing compaction
rightaway is not going to be helpful because we need free pages in the
lower regions to be able to do that. And the page allocator allocated in
this region precisely because there was no memory available in lower regions.
So the alloc path just notes down the freshly used region's id.
Free path of page allocator:
---------------------------
When we enter this path, we know that some memory is being freed. Here we
check if the alloc path had noted down any region for compaction. If so,
we trigger the worker function that tries to compact that memory.
Also, we avoid any locking/synchronization overhead over this worker
function in the alloc/free path, by attaching appropriate semantics to the
available status flags etc, such that we won't need any special locking
around them.
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
---
mm/page_alloc.c | 61 +++++++++++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 57 insertions(+), 4 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index db7b892..675a435 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -631,6 +631,7 @@ static void add_to_freelist(struct page *page, struct free_list *free_list,
struct list_head *prev_region_list, *lru;
struct mem_region_list *region;
int region_id, prev_region_id;
+ struct mem_power_ctrl *mpc;
lru = &page->lru;
region_id = page_zone_region_id(page);
@@ -639,6 +640,17 @@ static void add_to_freelist(struct page *page, struct free_list *free_list,
region->nr_free++;
region->zone_region->nr_free += 1 << order;
+ /*
+ * If the alloc path detected the usage of a new region, now is
+ * the time to complete the handshake and queue a worker
+ * to try compaction on that region.
+ */
+ mpc = &page_zone(page)->mem_power_ctrl;
+ if (!is_mem_pwr_work_in_progress(mpc) && mpc->region) {
+ set_mem_pwr_work_in_progress(mpc);
+ queue_work(system_unbound_wq, &mpc->work);
+ }
+
if (region->page_block) {
list_add_tail(lru, region->page_block);
return;
@@ -696,7 +708,9 @@ static void rmqueue_del_from_freelist(struct page *page,
{
struct list_head *lru = &page->lru;
struct mem_region_list *mr_list;
- int region_id;
+ struct zone_mem_region *zmr;
+ struct mem_power_ctrl *mpc;
+ int region_id, mt;
#ifdef CONFIG_DEBUG_PAGEALLOC
WARN((free_list->list.next != lru),
@@ -706,8 +720,27 @@ static void rmqueue_del_from_freelist(struct page *page,
list_del(lru);
/* Fastpath */
+ region_id = free_list->next_region - free_list->mr_list;
mr_list = free_list->next_region;
- mr_list->zone_region->nr_free -= 1 << order;
+ zmr = mr_list->zone_region;
+ if (region_id != 0 && (zmr->nr_free == zmr->present_pages)) {
+ /*
+ * This is the first alloc in this memory region. So try
+ * compacting this region in the near future. Don't bother
+ * if this is an unmovable/non-reclaimable allocation.
+ * Also don't try compacting region 0 because its pointless.
+ */
+ mt = get_freepage_migratetype(page);
+ if (is_migrate_cma(mt) || mt == MIGRATE_MOVABLE ||
+ mt == MIGRATE_RECLAIMABLE) {
+
+ mpc = &page_zone(page)->mem_power_ctrl;
+ if (!is_mem_pwr_work_in_progress(mpc))
+ mpc->region = zmr;
+ }
+ }
+
+ zmr->nr_free -= 1 << order;
if (--(mr_list->nr_free)) {
@@ -723,7 +756,6 @@ static void rmqueue_del_from_freelist(struct page *page,
* in this freelist.
*/
free_list->next_region->page_block = NULL;
- region_id = free_list->next_region - free_list->mr_list;
clear_region_bit(region_id, free_list);
/* Set 'next_region' to the new first region in the freelist. */
@@ -736,7 +768,9 @@ static void del_from_freelist(struct page *page, struct free_list *free_list,
{
struct list_head *prev_page_lru, *lru, *p;
struct mem_region_list *region;
- int region_id;
+ struct zone_mem_region *zmr;
+ struct mem_power_ctrl *mpc;
+ int region_id, mt;
lru = &page->lru;
@@ -746,6 +780,25 @@ static void del_from_freelist(struct page *page, struct free_list *free_list,
region_id = page_zone_region_id(page);
region = &free_list->mr_list[region_id];
+
+ zmr = region->zone_region;
+ if (region_id != 0 && (zmr->nr_free == zmr->present_pages)) {
+ /*
+ * This is the first alloc in this memory region. So try
+ * compacting this region in the near future. Don't bother
+ * if this is an unmovable/non-reclaimable allocation.
+ * Also don't try compacting region 0 because its pointless.
+ */
+ mt = get_freepage_migratetype(page);
+ if (is_migrate_cma(mt) || mt == MIGRATE_MOVABLE ||
+ mt == MIGRATE_RECLAIMABLE) {
+
+ mpc = &page_zone(page)->mem_power_ctrl;
+ if (!is_mem_pwr_work_in_progress(mpc))
+ mpc->region = zmr;
+ }
+ }
+
region->nr_free--;
region->zone_region->nr_free -= 1 << order;
--
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>
next prev parent reply other threads:[~2013-04-09 21:52 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-09 21:45 [RFC PATCH v2 00/15][Sorted-buddy] mm: Memory Power Management Srivatsa S. Bhat
2013-04-09 21:45 ` [RFC PATCH v2 01/15] mm: Introduce memory regions data-structure to capture region boundaries within nodes Srivatsa S. Bhat
2013-04-09 21:46 ` [RFC PATCH v2 02/15] mm: Initialize node memory regions during boot Srivatsa S. Bhat
2013-04-09 21:46 ` [RFC PATCH v2 03/15] mm: Introduce and initialize zone memory regions Srivatsa S. Bhat
2013-04-09 21:46 ` [RFC PATCH v2 04/15] mm: Add helpers to retrieve node region and zone region for a given page Srivatsa S. Bhat
2013-04-09 21:46 ` [RFC PATCH v2 05/15] mm: Add data-structures to describe memory regions within the zones' freelists Srivatsa S. Bhat
2013-04-09 21:47 ` [RFC PATCH v2 06/15] mm: Demarcate and maintain pageblocks in region-order in " Srivatsa S. Bhat
2013-04-09 21:47 ` [RFC PATCH v2 07/15] mm: Add an optimized version of del_from_freelist to keep page allocation fast Srivatsa S. Bhat
2013-04-09 21:47 ` [RFC PATCH v2 08/15] bitops: Document the difference in indexing between fls() and __fls() Srivatsa S. Bhat
2013-04-09 21:47 ` [RFC PATCH v2 09/15] mm: A new optimized O(log n) sorting algo to speed up buddy-sorting Srivatsa S. Bhat
2013-04-09 21:47 ` [RFC PATCH v2 10/15] mm: Add support to accurately track per-memory-region allocation Srivatsa S. Bhat
2013-04-09 21:48 ` [RFC PATCH v2 11/15] mm: Restructure the compaction part of CMA for wider use Srivatsa S. Bhat
2013-04-09 21:48 ` [RFC PATCH v2 12/15] mm: Add infrastructure to evacuate memory regions using compaction Srivatsa S. Bhat
2013-04-09 21:48 ` [RFC PATCH v2 13/15] mm: Implement the worker function for memory region compaction Srivatsa S. Bhat
2013-04-09 21:48 ` Srivatsa S. Bhat [this message]
2013-04-10 23:26 ` [RFC PATCH v2 14/15] mm: Add alloc-free handshake to trigger " Cody P Schafer
2013-04-16 13:49 ` Srivatsa S. Bhat
2013-04-09 21:49 ` [RFC PATCH v2 15/15] mm: Print memory region statistics to understand the buddy allocator behavior Srivatsa S. Bhat
2013-04-17 16:53 ` [RFC PATCH v2 00/15][Sorted-buddy] mm: Memory Power Management Srinivas Pandruvada
2013-04-18 9:54 ` Srivatsa S. Bhat
2013-04-18 15:13 ` Srinivas Pandruvada
2013-04-19 8:11 ` Srivatsa S. Bhat
2013-04-18 17:10 ` Dave Hansen
2013-04-19 6:50 ` Srivatsa S. Bhat
2013-04-25 17:57 ` Srivatsa S. Bhat
2013-04-19 5:34 ` Simon Jeons
2013-04-19 7:12 ` Srivatsa S. Bhat
2013-04-19 15:26 ` Srinivas Pandruvada
2013-05-28 20:08 ` Phillip Susi
2013-05-29 5:36 ` Srivatsa S. Bhat
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=20130409214853.4500.63619.stgit@srivatsabhat.in.ibm.com \
--to=srivatsa.bhat@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=amit.kachhap@linaro.org \
--cc=andi@firstfloor.org \
--cc=arjan@linux.intel.com \
--cc=dave@sr71.net \
--cc=gargankita@gmail.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kmpark@infradead.org \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-pm@vger.kernel.org \
--cc=loic.pallardy@stericsson.com \
--cc=matthew.garrett@nebula.com \
--cc=maxime.coquelin@stericsson.com \
--cc=mgorman@suse.de \
--cc=paulmck@linux.vnet.ibm.com \
--cc=riel@redhat.com \
--cc=rientjes@google.com \
--cc=rjw@sisk.pl \
--cc=santosh.shilimkar@ti.com \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=svaidy@linux.vnet.ibm.com \
--cc=thomas.abraham@linaro.org \
--cc=wujianguo@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).