From: Roman Gushchin <guroan@gmail.com>
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org,
Matthew Wilcox <willy@infradead.org>,
Johannes Weiner <hannes@cmpxchg.org>,
kernel-team@fb.com, Roman Gushchin <guro@fb.com>
Subject: [PATCH 1/3] mm: refactor __vunmap() to avoid duplicated call to find_vm_area()
Date: Mon, 25 Feb 2019 12:30:35 -0800 [thread overview]
Message-ID: <20190225203037.1317-2-guro@fb.com> (raw)
In-Reply-To: <20190225203037.1317-1-guro@fb.com>
__vunmap() calls find_vm_area() twice without an obvious reason:
first directly to get the area pointer, second indirectly by calling
remove_vm_area(), which is again searching for the area.
To remove this redundancy, let's split remove_vm_area() into
__remove_vm_area(struct vmap_area *), which performs the actual area
removal, and remove_vm_area(const void *addr) wrapper, which can
be used everywhere, where it has been used before.
On my test setup, I've got 5-10% speed up on vfree()'ing 1000000
of 4-pages vmalloc blocks.
Perf report before:
22.64% cat [kernel.vmlinux] [k] free_pcppages_bulk
10.30% cat [kernel.vmlinux] [k] __vunmap
9.80% cat [kernel.vmlinux] [k] find_vmap_area
8.11% cat [kernel.vmlinux] [k] vunmap_page_range
4.20% cat [kernel.vmlinux] [k] __slab_free
3.56% cat [kernel.vmlinux] [k] __list_del_entry_valid
3.46% cat [kernel.vmlinux] [k] smp_call_function_many
3.33% cat [kernel.vmlinux] [k] kfree
3.32% cat [kernel.vmlinux] [k] free_unref_page
Perf report after:
23.01% cat [kernel.kallsyms] [k] free_pcppages_bulk
9.46% cat [kernel.kallsyms] [k] __vunmap
9.15% cat [kernel.kallsyms] [k] vunmap_page_range
6.17% cat [kernel.kallsyms] [k] __slab_free
5.61% cat [kernel.kallsyms] [k] kfree
4.86% cat [kernel.kallsyms] [k] bad_range
4.67% cat [kernel.kallsyms] [k] free_unref_page_commit
4.24% cat [kernel.kallsyms] [k] __list_del_entry_valid
3.68% cat [kernel.kallsyms] [k] free_unref_page
3.65% cat [kernel.kallsyms] [k] __list_add_valid
3.19% cat [kernel.kallsyms] [k] __purge_vmap_area_lazy
3.10% cat [kernel.kallsyms] [k] find_vmap_area
3.05% cat [kernel.kallsyms] [k] rcu_cblist_dequeue
Signed-off-by: Roman Gushchin <guro@fb.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Matthew Wilcox <willy@infradead.org>
---
mm/vmalloc.c | 47 +++++++++++++++++++++++++++--------------------
1 file changed, 27 insertions(+), 20 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index b7455d4c8c12..8f0179895fb5 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1477,6 +1477,24 @@ struct vm_struct *find_vm_area(const void *addr)
return NULL;
}
+static struct vm_struct *__remove_vm_area(struct vmap_area *va)
+{
+ struct vm_struct *vm = va->vm;
+
+ might_sleep();
+
+ spin_lock(&vmap_area_lock);
+ va->vm = NULL;
+ va->flags &= ~VM_VM_AREA;
+ va->flags |= VM_LAZY_FREE;
+ spin_unlock(&vmap_area_lock);
+
+ kasan_free_shadow(vm);
+ free_unmap_vmap_area(va);
+
+ return vm;
+}
+
/**
* remove_vm_area - find and remove a continuous kernel virtual area
* @addr: base address
@@ -1489,31 +1507,20 @@ struct vm_struct *find_vm_area(const void *addr)
*/
struct vm_struct *remove_vm_area(const void *addr)
{
+ struct vm_struct *vm = NULL;
struct vmap_area *va;
- might_sleep();
-
va = find_vmap_area((unsigned long)addr);
- if (va && va->flags & VM_VM_AREA) {
- struct vm_struct *vm = va->vm;
-
- spin_lock(&vmap_area_lock);
- va->vm = NULL;
- va->flags &= ~VM_VM_AREA;
- va->flags |= VM_LAZY_FREE;
- spin_unlock(&vmap_area_lock);
-
- kasan_free_shadow(vm);
- free_unmap_vmap_area(va);
+ if (va && va->flags & VM_VM_AREA)
+ vm = __remove_vm_area(va);
- return vm;
- }
- return NULL;
+ return vm;
}
static void __vunmap(const void *addr, int deallocate_pages)
{
struct vm_struct *area;
+ struct vmap_area *va;
if (!addr)
return;
@@ -1522,17 +1529,18 @@ static void __vunmap(const void *addr, int deallocate_pages)
addr))
return;
- area = find_vm_area(addr);
- if (unlikely(!area)) {
+ va = find_vmap_area((unsigned long)addr);
+ if (unlikely(!va || !(va->flags & VM_VM_AREA))) {
WARN(1, KERN_ERR "Trying to vfree() nonexistent vm area (%p)\n",
addr);
return;
}
+ area = va->vm;
debug_check_no_locks_freed(area->addr, get_vm_area_size(area));
debug_check_no_obj_freed(area->addr, get_vm_area_size(area));
- remove_vm_area(addr);
+ __remove_vm_area(va);
if (deallocate_pages) {
int i;
@@ -1547,7 +1555,6 @@ static void __vunmap(const void *addr, int deallocate_pages)
}
kfree(area);
- return;
}
static inline void __vfree_deferred(const void *addr)
--
2.20.1
next parent reply other threads:[~2019-02-25 20:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190225203037.1317-1-guro@fb.com>
2019-02-25 20:30 ` Roman Gushchin [this message]
2019-02-28 15:00 ` Vlastimil Babka
2019-02-25 20:30 ` [PATCH 2/3] mm: separate memory allocation and actual work in alloc_vmap_area() Roman Gushchin
2019-03-01 14:43 ` Vlastimil Babka
2019-03-01 16:48 ` Roman Gushchin
2019-04-17 13:27 ` Vlastimil Babka
2019-04-17 19:15 ` Roman Gushchin
2019-02-25 20:30 ` [PATCH 3/3] mm: show number of vmalloc pages in /proc/meminfo Roman Gushchin
2019-03-01 15:05 ` Vlastimil Babka
2019-04-17 13:34 ` Vlastimil Babka
2019-03-29 22:07 ` [PATCH 0/3] vmalloc enhancements Roman Gushchin
2019-04-17 13:36 ` Vlastimil Babka
2018-12-19 17:37 Roman Gushchin
2018-12-19 17:37 ` [PATCH 1/3] mm: refactor __vunmap() to avoid duplicated call to find_vm_area() Roman Gushchin
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=20190225203037.1317-2-guro@fb.com \
--to=guroan@gmail.com \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=willy@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox