From: Xing Zhengjun <zhengjun.xing@linux.intel.com>
To: linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>
Cc: Dave Hansen <dave.hansen@intel.com>, Tony <tony.luck@intel.com>,
Tim C Chen <tim.c.chen@intel.com>,
"Huang, Ying" <ying.huang@intel.com>,
"Du, Julie" <julie.du@intel.com>
Subject: Test report for kernel direct mapping performance
Date: Fri, 15 Jan 2021 15:23:07 +0800 [thread overview]
Message-ID: <213b4567-46ce-f116-9cdf-bbd0c884eb3c@linux.intel.com> (raw)
Hi,
There is currently a bit of a debate about the kernel direct map. Does
using 2M/1G pages aggressively for the kernel direct map help
performance? Or, is it an old optimization which is not as helpful on
modern CPUs as it was in the old days? What is the penalty of a kernel
feature that heavily demotes this mapping from larger to smaller pages?
We did a set of runs with 1G and 2M pages enabled /disabled and saw the
changes.
[Conclusions]
Assuming that this was a good representative set of workloads and that
the data are good, for server usage, we conclude that the existing
aggressive use of 1G mappings is a good choice since it represents the
best in a plurality of the workloads. However, in a *majority* of cases,
another mapping size (2M or 4k) potentially offers a performance
improvement. This leads us to conclude that although 1G mappings are a
good default choice, there is no compelling evidence that it must be the
only choice, or that folks deriving benefits (like hardening) from
smaller mapping sizes should avoid the smaller mapping sizes.
[Summary of results]
1. The test was done on server platforms with 11 benchmarks. For the 4
different server platforms tested, each with three different maximums
kernel mapping sizes: 4k, 2M, and 1G. Each system has enough memory to
effectively deploy 1G mappings. For the 11 different benchmarks were
used, not every benchmark was run on every system, there was a total of
259 tests.
2. For each benchmark/system combination, the 1G mapping had the highest
performance for 45% of the tests, 2M for ~30%, and 4k for~20%.
3. From the average delta, among 1G/2M/4K, 4K gets the lowest
performance in all the 4 test machines, while 1G gets the best
performance on 2 test machines and 2M gets the best performance on the
other 2 machines.
4. By testing with machine memory from 256G to 512G, we observed that
the larger memory will lead to the performance better for 1G page size.
With Large memory,
Will-it-scale/vm-scalability/unixbench/reaim/hackbench shows 1G has the
best performance, while kbuild/memtier/netperf shows 4K has the best
performance.
For more details please see the following web link:
https://01.org/sites/default/files/documentation/test_report_for_kernel_direct_mapping_performance_0.pdf
--
Zhengjun Xing
next reply other threads:[~2021-01-15 7:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-15 7:23 Xing Zhengjun [this message]
2021-01-26 15:00 ` Test report for kernel direct mapping performance Michal Hocko
2021-01-27 7:50 ` Xing Zhengjun
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=213b4567-46ce-f116-9cdf-bbd0c884eb3c@linux.intel.com \
--to=zhengjun.xing@linux.intel.com \
--cc=dave.hansen@intel.com \
--cc=julie.du@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=tim.c.chen@intel.com \
--cc=tony.luck@intel.com \
--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;
as well as URLs for NNTP newsgroup(s).