From: Prathu Baronia <prathu.baronia@oneplus.com>
To: akpm@linux-foundation.org, linux-mm@kvack.org
Cc: gregkh@linuxfoundation.org, gthelen@google.com, jack@suse.cz,
mhocko@suse.com, ken.lin@oneplus.com, gasine.xu@oneplus.com,
chintan.pandya@oneplus.com
Subject: [RFC] mm/memory.c: Optimizing THP zeroing routine for !HIGHMEM cases
Date: Fri, 3 Apr 2020 13:48:14 +0530 [thread overview]
Message-ID: <20200403081812.GA14090@oneplus.com> (raw)
THP allocation for anon memory requires zeroing of the huge page. To do so,
we iterate over 2MB memory in 4KB chunks. Each iteration calls for kmap_atomic()
and kunmap_atomic(). This routine makes sense where we need temporary mapping of
the user page. In !HIGHMEM cases, specially in 64-bit architectures, we don't
need temp mapping. Hence, kmap_atomic() acts as nothing more than multiple
barrier() calls.
This called for optimization. Simply getting VADDR from page does the job for
us. So, implement another (optimized) routine for clear_huge_page() which
doesn't need temporary mapping of user space page.
While testing this patch on Qualcomm SM8150 SoC (kernel v4.14.117), we see 64%
Improvement in clear_huge_page().
Ftrace results:
Default profile:
------------------------------------------
6) ! 473.802 us | clear_huge_page();
------------------------------------------
With this patch applied:
------------------------------------------
5) ! 170.156 us | clear_huge_page();
------------------------------------------
Signed-off-by: Prathu Baronia <prathu.baronia@oneplus.com>
Reported-by: Chintan Pandya <chintan.pandya@oneplus.com>
---
mm/memory.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/mm/memory.c b/mm/memory.c
index 3ee073d..3e120e8 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -5119,6 +5119,7 @@ EXPORT_SYMBOL(__might_fault);
#endif
#if defined(CONFIG_TRANSPARENT_HUGEPAGE) || defined(CONFIG_HUGETLBFS)
+#ifdef CONFIG_HIGHMEM
static void clear_gigantic_page(struct page *page,
unsigned long addr,
unsigned int pages_per_huge_page)
@@ -5183,6 +5184,16 @@ void clear_huge_page(struct page *page,
addr + right_idx * PAGE_SIZE);
}
}
+#else
+void clear_huge_page(struct page *page,
+ unsigned long addr_hint, unsigned int pages_per_huge_page)
+{
+ void *addr;
+
+ addr = page_address(page);
+ memset(addr, 0, pages_per_huge_page*PAGE_SIZE);
+}
+#endif
static void copy_user_gigantic_page(struct page *dst, struct page *src,
unsigned long addr,
--
2.7.4
--
Prathu Baronia
next reply other threads:[~2020-04-03 8:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-03 8:18 Prathu Baronia [this message]
2020-04-03 8:52 ` [RFC] mm/memory.c: Optimizing THP zeroing routine for !HIGHMEM cases Michal Hocko
2020-04-09 15:29 ` Prathu Baronia
2020-04-09 15:45 ` Michal Hocko
[not found] ` <SG2PR04MB2921D2AAA8726318EF53D83691DE0@SG2PR04MB2921.apcprd04.prod.outlook.com>
2020-04-10 9:05 ` Huang, Ying
2020-04-11 15:40 ` Chintan Pandya
2020-04-11 20:47 ` Alexander Duyck
2020-04-13 15:33 ` Prathu Baronia
2020-04-13 16:24 ` Alexander Duyck
2020-04-14 1:10 ` Huang, Ying
2020-04-10 18:54 ` Alexander Duyck
2020-04-11 8:45 ` Chintan Pandya
2020-04-14 15:55 ` Daniel Jordan
2020-04-14 17:33 ` Chintan Pandya
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=20200403081812.GA14090@oneplus.com \
--to=prathu.baronia@oneplus.com \
--cc=akpm@linux-foundation.org \
--cc=chintan.pandya@oneplus.com \
--cc=gasine.xu@oneplus.com \
--cc=gregkh@linuxfoundation.org \
--cc=gthelen@google.com \
--cc=jack@suse.cz \
--cc=ken.lin@oneplus.com \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.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).