From: Prathu Baronia <prathu.baronia@oneplus.com>
To: catalin.marinas@arm.com
Cc: alexander.duyck@gmail.com, chintan.pandya@oneplus.com,
mhocko@suse.com, akpm@linux-foundation.org, linux-mm@kvack.org,
gregkh@linuxfoundation.com, gthelen@google.com, jack@suse.cz,
ken.lin@oneplus.com, gasine.xu@oneplus.com, ying.huang@intel.com,
mark.rutland@arm.com, will@kernel.org
Subject: Re: [PATCH v2] mm: Optimized hugepage zeroing & copying from user
Date: Tue, 21 Apr 2020 15:06:21 +0530 [thread overview]
Message-ID: <20200421093621.3fuptvf2qbyfzwfz@oneplus.com> (raw)
In-Reply-To: <87k12bt3ff.fsf@yhuang-dev.intel.com>
With below v2 patch we observe a significantly(~65%) improved zeroing time for
hugepages.
We profiled the clear_huge_page() using ftrace on Qualcomm's SM8150 platform
under controlled conditions(i.e. only CPU0 and 6 turned on and set to max
frequency, and DDR set to performance governor).
The existing method uses a reverse traversal of a section of a hugepage which
based on our series of experiments proves slower than a oneshot(v2) approach on
ARM64.(more details in mail thread)
We didn't see any benefit on x86 so v2 probably won't find any place in the main
memory.c code.
We are currently thinking of making this optimization ARM64 specific for better
performance by placing this in arch/arm64/mm/memory.c(to be created) file. We
would really appreciate if you can share your opinion on this.
--
Prathu Baronia
OnePlus RnD
next prev parent reply other threads:[~2020-04-21 9:36 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-14 15:38 Prathu Baronia
2020-04-14 17:03 ` Michal Hocko
2020-04-14 17:41 ` Daniel Jordan
[not found] ` <20200414184743.GB2097@oneplus.com>
2020-04-14 19:32 ` Alexander Duyck
2020-04-15 3:40 ` Huang, Ying
2020-04-15 11:09 ` Michal Hocko
2020-04-19 12:05 ` Prathu Baronia
2020-04-14 19:40 ` Michal Hocko
2020-04-15 3:27 ` Huang, Ying
2020-04-16 1:21 ` Huang, Ying
2020-04-19 15:58 ` Prathu Baronia
2020-04-20 0:18 ` Huang, Ying
2020-04-21 9:36 ` Prathu Baronia [this message]
2020-04-21 10:09 ` Will Deacon
2020-04-21 12:47 ` Vlastimil Babka
2020-04-21 12:48 ` Vlastimil Babka
2020-04-21 13:39 ` Will Deacon
2020-04-21 13:48 ` Vlastimil Babka
2020-04-21 13:56 ` Chintan Pandya
2020-04-22 8:18 ` Will Deacon
2020-04-22 11:19 ` Will Deacon
2020-04-22 14:38 ` Prathu Baronia
2020-05-01 8:58 ` Prathu Baronia
2020-05-05 8:59 ` Will Deacon
2020-04-21 13:00 ` Michal Hocko
2020-04-21 13:10 ` Will Deacon
2020-04-17 7:48 ` [mm] 134c8b410f: vm-scalability.median -7.9% regression kernel test robot
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=20200421093621.3fuptvf2qbyfzwfz@oneplus.com \
--to=prathu.baronia@oneplus.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.duyck@gmail.com \
--cc=catalin.marinas@arm.com \
--cc=chintan.pandya@oneplus.com \
--cc=gasine.xu@oneplus.com \
--cc=gregkh@linuxfoundation.com \
--cc=gthelen@google.com \
--cc=jack@suse.cz \
--cc=ken.lin@oneplus.com \
--cc=linux-mm@kvack.org \
--cc=mark.rutland@arm.com \
--cc=mhocko@suse.com \
--cc=will@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox