All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aaron Lu <aaron.lu@intel.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Dave Hansen <dave.hansen@intel.com>,
	Tim Chen <tim.c.chen@intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ying Huang <ying.huang@intel.com>
Subject: Re: [PATCH v2 0/5] mm: support parallel free of memory
Date: Fri, 17 Mar 2017 11:10:48 +0800	[thread overview]
Message-ID: <20170317031048.GC18964@aaronlu.sh.intel.com> (raw)
In-Reply-To: <c2e172b1-fb2a-57a0-0074-a07a61693e6c@suse.cz>

On Wed, Mar 15, 2017 at 03:56:02PM +0100, Vlastimil Babka wrote:
> I wonder if the difference would be larger if the parallelism was done
> on a higher level, something around unmap_page_range(). IIUC the current

I guess I misunderstand you in my last email - doing it at
unmap_page_range() level is essentially doing it at a per-VMA level
since it is the main function used in unmap_single_vma(). We have tried
that and felt that it's not flexible as the proposed approach since
it wouldn't parallize well for:
1 work load that uses only 1 or very few huge VMA;
2 work load that has a lot of small VMAs.

The code is nice and easy though(developed at v4.9 time frame):

>From f6d5cfde888b9e0356719fabe8754fdfe6fe236b Mon Sep 17 00:00:00 2001
From: Aaron Lu <aaron.lu@intel.com>
Date: Wed, 11 Jan 2017 15:56:06 +0800
Subject: [PATCH] mm: async free vma

---
 include/linux/mm_types.h |  6 ++++++
 mm/memory.c              | 23 ++++++++++++++++++++++-
 2 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 4a8acedf4b7d..d10d2ce8f8f4 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -358,6 +358,12 @@ struct vm_area_struct {
 	struct mempolicy *vm_policy;	/* NUMA policy for the VMA */
 #endif
 	struct vm_userfaultfd_ctx vm_userfaultfd_ctx;
+
+	struct vma_free_ctx {
+		unsigned long start_addr;
+		unsigned long end_addr;
+		struct work_struct work;
+	} free_ctx;
 };
 
 struct core_thread {
diff --git a/mm/memory.c b/mm/memory.c
index e18c57bdc75c..0fe4e45a044b 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1345,6 +1345,17 @@ static void unmap_single_vma(struct mmu_gather *tlb,
 	}
 }
 
+static void unmap_single_vma_work(struct work_struct *work)
+{
+	struct vma_free_ctx *ctx = container_of(work, struct vma_free_ctx, work);
+	struct vm_area_struct *vma = container_of(ctx, struct vm_area_struct, free_ctx);
+	struct mmu_gather tlb;
+
+	tlb_gather_mmu(&tlb, vma->vm_mm, ctx->start_addr, ctx->end_addr);
+	unmap_single_vma(&tlb, vma, ctx->start_addr, ctx->end_addr, NULL);
+	tlb_finish_mmu(&tlb, ctx->start_addr, ctx->end_addr);
+}
+
 /**
  * unmap_vmas - unmap a range of memory covered by a list of vma's
  * @tlb: address of the caller's struct mmu_gather
@@ -1368,10 +1379,20 @@ void unmap_vmas(struct mmu_gather *tlb,
 		unsigned long end_addr)
 {
 	struct mm_struct *mm = vma->vm_mm;
+	struct vma_free_ctx *ctx;
+	struct vm_area_struct *tmp = vma;
 
 	mmu_notifier_invalidate_range_start(mm, start_addr, end_addr);
+	for ( ; vma && vma->vm_start < end_addr; vma = vma->vm_next) {
+		ctx = &vma->free_ctx;
+		ctx->start_addr = start_addr;
+		ctx->end_addr = end_addr;
+		INIT_WORK(&ctx->work, unmap_single_vma_work);
+		queue_work(system_unbound_wq, &ctx->work);
+	}
+	vma = tmp;
 	for ( ; vma && vma->vm_start < end_addr; vma = vma->vm_next)
-		unmap_single_vma(tlb, vma, start_addr, end_addr, NULL);
+		flush_work(&vma->free_ctx.work);
 	mmu_notifier_invalidate_range_end(mm, start_addr, end_addr);
 }
 
-- 
2.9.3

WARNING: multiple messages have this Message-ID (diff)
From: Aaron Lu <aaron.lu@intel.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Dave Hansen <dave.hansen@intel.com>,
	Tim Chen <tim.c.chen@intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ying Huang <ying.huang@intel.com>
Subject: Re: [PATCH v2 0/5] mm: support parallel free of memory
Date: Fri, 17 Mar 2017 11:10:48 +0800	[thread overview]
Message-ID: <20170317031048.GC18964@aaronlu.sh.intel.com> (raw)
In-Reply-To: <c2e172b1-fb2a-57a0-0074-a07a61693e6c@suse.cz>

On Wed, Mar 15, 2017 at 03:56:02PM +0100, Vlastimil Babka wrote:
> I wonder if the difference would be larger if the parallelism was done
> on a higher level, something around unmap_page_range(). IIUC the current

I guess I misunderstand you in my last email - doing it at
unmap_page_range() level is essentially doing it at a per-VMA level
since it is the main function used in unmap_single_vma(). We have tried
that and felt that it's not flexible as the proposed approach since
it wouldn't parallize well for:
1 work load that uses only 1 or very few huge VMA;
2 work load that has a lot of small VMAs.

The code is nice and easy though(developed at v4.9 time frame):

  parent reply	other threads:[~2017-03-17  3:11 UTC|newest]

Thread overview: 84+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-15  8:59 [PATCH v2 0/5] mm: support parallel free of memory Aaron Lu
2017-03-15  8:59 ` Aaron Lu
2017-03-15  9:00 ` [PATCH v2 1/5] mm: add tlb_flush_mmu_free_batches Aaron Lu
2017-03-15  9:00   ` Aaron Lu
2017-03-15  9:00 ` [PATCH v2 2/5] mm: parallel free pages Aaron Lu
2017-03-15  9:00   ` Aaron Lu
2017-03-15  9:42   ` Hillf Danton
2017-03-15  9:42     ` Hillf Danton
2017-03-15 11:54     ` Aaron Lu
2017-03-15 11:54       ` Aaron Lu
2017-03-15  9:00 ` [PATCH v2 3/5] mm: use a dedicated workqueue for the free workers Aaron Lu
2017-03-15  9:00   ` Aaron Lu
2017-03-22  6:33   ` Minchan Kim
2017-03-22  6:33     ` Minchan Kim
2017-03-22  8:41     ` Aaron Lu
2017-03-22  8:41       ` Aaron Lu
2017-03-22  8:55       ` Minchan Kim
2017-03-22  8:55         ` Minchan Kim
2017-03-22 13:43         ` Aaron Lu
2017-03-22 13:43           ` Aaron Lu
2017-03-23  5:53           ` Minchan Kim
2017-03-23  5:53             ` Minchan Kim
2017-03-23 15:38       ` Dave Hansen
2017-03-23 15:38         ` Dave Hansen
2017-03-24 12:37         ` Aaron Lu
2017-03-24 12:37           ` Aaron Lu
2017-03-15  9:00 ` [PATCH v2 4/5] mm: add force_free_pages in zap_pte_range Aaron Lu
2017-03-15  9:00   ` Aaron Lu
2017-03-15  9:00 ` [PATCH v2 5/5] mm: add debugfs interface for parallel free tuning Aaron Lu
2017-03-15  9:00   ` Aaron Lu
2017-03-15 14:18 ` [PATCH v2 0/5] mm: support parallel free of memory Michal Hocko
2017-03-15 14:18   ` Michal Hocko
2017-03-15 15:44   ` Aaron Lu
2017-03-15 15:44     ` Aaron Lu
2017-03-15 16:28     ` Michal Hocko
2017-03-15 16:28       ` Michal Hocko
2017-03-15 21:38       ` Tim Chen
2017-03-15 21:38         ` Tim Chen
2017-03-16  9:07         ` Michal Hocko
2017-03-16  9:07           ` Michal Hocko
2017-03-16 18:36           ` Tim Chen
2017-03-16 18:36             ` Tim Chen
2017-03-17  7:47             ` Michal Hocko
2017-03-17  7:47               ` Michal Hocko
2017-03-17  8:07               ` Minchan Kim
2017-03-17  8:07                 ` Minchan Kim
2017-03-17 12:33               ` Aaron Lu
2017-03-17 12:33                 ` Aaron Lu
2017-03-17 12:59                 ` Michal Hocko
2017-03-17 12:59                   ` Michal Hocko
2017-03-17 13:16                 ` Peter Zijlstra
2017-03-17 13:16                   ` Peter Zijlstra
2017-03-17 12:53               ` Peter Zijlstra
2017-03-17 12:53                 ` Peter Zijlstra
2017-03-17 13:05                 ` Michal Hocko
2017-03-17 13:05                   ` Michal Hocko
2017-03-21 14:54           ` Dave Hansen
2017-03-21 14:54             ` Dave Hansen
2017-03-22  8:02             ` Aaron Lu
2017-03-22  8:02               ` Aaron Lu
2017-03-24  7:04             ` Aaron Lu
2017-03-24  7:04               ` Aaron Lu
2017-03-21 15:18           ` Tim Chen
2017-03-21 15:18             ` Tim Chen
2017-03-16  6:54       ` Aaron Lu
2017-03-16  6:54         ` Aaron Lu
2017-03-16  7:34       ` Aaron Lu
2017-03-16  7:34         ` Aaron Lu
2017-03-16 13:51         ` Aaron Lu
2017-03-16 13:51           ` Aaron Lu
2017-03-16 14:14           ` Aaron Lu
2017-03-16 14:14             ` Aaron Lu
2017-03-15 14:56 ` Vlastimil Babka
2017-03-15 14:56   ` Vlastimil Babka
2017-03-15 15:50   ` Aaron Lu
2017-03-15 15:50     ` Aaron Lu
2017-03-17  3:10   ` Aaron Lu [this message]
2017-03-17  3:10     ` Aaron Lu
2017-03-16 19:38 ` Alex Thorlton
2017-03-16 19:38   ` Alex Thorlton
2017-03-17  2:21   ` Aaron Lu
2017-03-17  2:21     ` Aaron Lu
2017-03-20 19:15     ` Alex Thorlton
2017-03-20 19:15       ` Alex Thorlton

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=20170317031048.GC18964@aaronlu.sh.intel.com \
    --to=aaron.lu@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=dave.hansen@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=tim.c.chen@intel.com \
    --cc=vbabka@suse.cz \
    --cc=ying.huang@intel.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.