From: Yang Huan <link@vivo.com>
To: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: kernel@vivo.com, Yang Huan <link@vivo.com>
Subject: [PATCH] mm/vmalloc: try alloc_pages_bulk first to get order 0 pages fast
Date: Fri, 9 Jul 2021 17:28:31 +0800 [thread overview]
Message-ID: <20210709092831.10602-1-link@vivo.com> (raw)
Vmalloc may offen get pages by loop invoke alloc_pags, this is
cost too much time in count watermark/cpuset or something.
Let's just try alloc by alloc_pages_bulk, if failed, fullback in
original path.
With my own test, simulate loop alloc_page and alloc_pages_bulk_array,
get this:
size 1M 10M 20M 30
normal 44 1278 3665 5581
test 34 889 2167 3300
optimize 22% 30% 40% 40%
And in my vmalloc top sort, zram/f2fs may alloc more than 20MB, so,
It's worth to use alloc_pages_bulk.
Signed-off-by: Yang Huan <link@vivo.com>
---
mm/vmalloc.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index a13ac524f6ff..b5af7b4e30bc 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -2791,17 +2791,23 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
}
area->pages = pages;
- area->nr_pages = nr_small_pages;
+ area->nr_pages = 0;
set_vm_area_page_order(area, page_shift - PAGE_SHIFT);
page_order = vm_area_page_order(area);
-
+ /* first try alloc in alloc bulk when order is 0*/
+ if (!page_order) {
+ area->nr_pages = alloc_pages_bulk_array(
+ gfp_mask, nr_small_pages, area->pages);
+ if (likely(area->nr_pages == nr_small_pages))
+ goto success;
+ }
/*
* Careful, we allocate and map page_order pages, but tracking is done
* per PAGE_SIZE page so as to keep the vm_struct APIs independent of
* the physical/mapped size.
*/
- for (i = 0; i < area->nr_pages; i += 1U << page_order) {
+ for (i = area->nr_pages; i < nr_small_pages; i += 1U << page_order) {
struct page *page;
int p;
@@ -2824,6 +2830,8 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
if (gfpflags_allow_blocking(gfp_mask))
cond_resched();
}
+ area->nr_pages = nr_small_pages;
+success:
atomic_long_add(area->nr_pages, &nr_vmalloc_pages);
if (vmap_pages_range(addr, addr + size, prot, pages, page_shift) < 0) {
--
2.32.0
next reply other threads:[~2021-07-09 9:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-09 9:28 Yang Huan [this message]
2021-07-09 9:38 ` [PATCH] mm/vmalloc: try alloc_pages_bulk first to get order 0 pages fast Mel Gorman
2021-07-09 9:53 ` 杨欢
2021-07-09 9:53 ` 杨欢
2021-07-09 22:29 ` Andrew Morton
2021-07-12 2:51 ` 杨欢
2021-07-12 2:51 ` 杨欢
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=20210709092831.10602-1-link@vivo.com \
--to=link@vivo.com \
--cc=akpm@linux-foundation.org \
--cc=kernel@vivo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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.