Dave McCracken wrote:
Here's a new version of my shared page tables patch.
The primary purpose of sharing page tables is improved performance for
large applications that share big memory areas between multiple processes.
It eliminates the redundant page tables and significantly reduces the
number of minor page faults. Tests show significant performance
improvement for large database applications, including those using large
pages. There is no measurable performance degradation for small processes.
Hi,
We evaluated page table sharing on x86_64 and ppc64 setups, using a database
OLTP workload. In both cases, 4-way systems with 64 GB of memory were used.
On the x86_64 setup, page table sharing provided a 25% increase in
performance,
when the database buffers were in small (4 KB) pages. In this case,
over 14 GB
of memory was freed, that had previously been taken up by page tables.
In the
case that the database buffers were in huge (2 MB) pages, page table sharing
provided a 4% increase in performance.
Our ppc64 experiments used an earlier version of Dave's patch, along with
ppc64-specific code for sharing of ppc64 segments. On this setup, page
table sharing provided a 49% increase in performance, when the database
buffers were in small (4 KB) pages. Over 10 GB of memory was freed, that
had previously been taken up by page tables. In the case that the database
buffers were in huge (16 MB) pages, page table sharing provided a 3%
increase
in performance.
In the experiments above, page table sharing brought performance with small
pages to within 12% of the performance observed with hugepages.
Given the results above, we are keen for page table sharing to get included,
for a couple of reasons. First, we feel it provides for significantly more
robust "out-of-the-box" performance for process-based middleware such as
DB2,
Oracle, and SAP. Customers don't have to use or even know about hugepages
to get near best-case performance. Secondly, the performance boost provided
will help efforts to publish proof points which can be used to advance the
adoption of Linux in performance-sensitive data-center environments.
Cheers,
Brian Twichell
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
