lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <213b4567-46ce-f116-9cdf-bbd0c884eb3c@linux.intel.com>
Date:   Fri, 15 Jan 2021 15:23:07 +0800
From:   Xing Zhengjun <zhengjun.xing@...ux.intel.com>
To:     linux-mm@...ck.org, LKML <linux-kernel@...r.kernel.org>
Cc:     Dave Hansen <dave.hansen@...el.com>, Tony <tony.luck@...el.com>,
        Tim C Chen <tim.c.chen@...el.com>,
        "Huang, Ying" <ying.huang@...el.com>,
        "Du, Julie" <julie.du@...el.com>
Subject: Test report for kernel direct mapping performance

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ