Java Performance: Huge Pages Investigated

Since experience tells us that it is quite rare for one CPU to beat another in a benchmark by a factor 3, we investigated the matter further. The most obvious candidate was Huge Pages, or as everybody besides the Linux community calls it: "Large Pages".

Every modern CPU caches the virtual-to-physical memory mappings in their TLBs. The "normal" size of a page is 4 KB, so with 1536 entries, the Skylake core can only cache about 6 MB per core. Consequently, as DRAM capacity has grown the past 15 years from a few GB to hundreds of GBs, TLB misses have become more and more of a concern. A TLB miss is quite expensive – costing several memory accesses in total – as you need to read out several tables to finally find the physical address.

All modern CPU support larger pages. In the x86-64 (Intel & AMD) a 2 MB large page is the most popular option, while a 1 GB page is also available. Meanwhile a large page on the ThunderX2 is no less than 0.5 GB. Using large pages reduces the number of TLB misses (although the number of entries in the TLB is typically much lower for large pages), and also they reduce the number of memory accesses needed if a TLB miss occurs.

However, it took a while before Linux supported this feature in an easy to handle way. Memory fragmentation, conflicting and hard to configure settings, incompatibilities, and especially very confusing names caused a lot of trouble. In fact, many software vendors still advise server admins to disable large pages. So while it was quickly embraced for benchmarks, the software community as a whole is still hesitant.

To that end, let's see what happens if we enable Transparent Huge Pages and keep the best settings we discussed on the previous page.

SPECJBB 2015-Multi Max-jOPS Huge pages impact

Overall, for Max-jOPs the performance impact is nothing spectaculair; in fact it's a slight regression. The Xeon loses about 1% of its throughput, the ThunderX2 about 5%.

Moving on, let's check out the Critical-jOPS metric, where throughput is measured with a 99 percentile response time constraint.

SPECJBB 2015-Multi Critical-jOPS  Huge pages impact

A massive difference! Instead of taking a massive beating, the Intel setup edges out the ThunderX2. Still, it must be said that performance with 4 KB pages seems to be a major weakness with Intel's architecture.

Java Performance Big Data Benchmarking: Apache Spark
Comments Locked

97 Comments

View All Comments

  • JohanAnandtech - Thursday, May 24, 2018 - link

    I have been trouble shooting a Java problem for the last 3 weeks now - for some reason our specific EPYC test system has some serious performance issues after we upgraded to kernel 4.13. This might be a hardware/firmware... issue. I don't know. I just know that the current tests are not accurate.
  • junky77 - Thursday, May 24, 2018 - link

    What? A 2.5GHZ ARM core is around 60-70% of a 3.8GHZ Skylake core?? For 3.8GHZ, the ARM is probably at least as fast?
  • Wilco1 - Thursday, May 24, 2018 - link

    Probably around 90% since performance doesn't scale linearly with frequency. Note these are throughput parts so won't clock that high. However a 7nm version might well reach 3GHz.
  • AJ_NEWMAN - Thursday, May 24, 2018 - link

    If Caviums tweaked 16nm hits 3GHz - it would to be unreasonable to aim for 4GHz for a 7nm part.

    With 2.3 times as many transistors available - it will be interesting to see what else they beef up?

    HIgher IPC? 64 cores? 16 memory controllers? CCIX - or perhaps they will compete with Fujitsu and add some Supercomputer centric hardware?

    AJ
  • meta.x.gdb - Thursday, May 31, 2018 - link

    Wonder why the VASP code limped along on ThunderX2 while OpenFOAM saw such gains. I'm pretty familiar with both codes. VASP is mostly doing density functional theory, which is FFT-heavy...
  • Meteor2 - Tuesday, June 26, 2018 - link

    All I want to say (all I can say) is that Anandtech has some of the best writers and commenters in this field. Fantastic article, and fantastic discussion.
  • paldU - Saturday, July 7, 2018 - link

    A typo in Page 2. "it terms of performance per dollar" should be " in terms of performance per dollar".

Log in

Don't have an account? Sign up now