[PATCH] D152834: A new code layout algorithm for function reordering [2/3]

[Snehasish Kumar via Phabricator via llvm-commits]

snehasish added a comment.

In D152834#4439489 <https://reviews.llvm.org/D152834#4439489>, @spupyrev wrote:

> Hmm. I was using "cpu/event=0x85,umask=0x61/u" for i-TLB misses, which we got from `https://download.01.org/perfmon`, which has even been moved since then. Back in 2017 (when the algorithm was developed) we thought this is the "right" event to look at, but it might not be the case. Which one would you recommend to look at? I see this page <https://github.com/intel/perfmon/blob/main/SKL/events/skylake_core.json> has a good description.

There are a few different sets of events which count iTLB related behaviours. The misses that matter most are the ones that stall the pipeline. This is counted by FRONTEND_RETIRED.ITLB_MISS. https://github.com/intel/perfmon/blob/main/SKL/events/skylake_core.json#L5117-L5137

For a raw count of iTLB misses which include speculative execution you can look at ICACHE64B.IFTAG_STALL (alias ICACHE_TAG.STALLS). It's unfortunately an un-intuitive name. https://github.com/intel/perfmon/blob/main/SKL/events/skylake_core.json#L2702-L2723

The set of events which use cpu/event=0x85 are meant to capture speculative and non-speculative execution triggered page walks (apart from one mask which counts sTLB hits). So I would recommend looking into the two mentioned above to quantify the impact more accurately for hugepages.

> Notice that when we turn on huge pages, the amount of iTLB misses decreases by ~10x, and the absolute differences between A and B sides are much smaller than when no huge pages are used.

Yes, as @rahmanl mentioned, with hugepages enabled there probably isn't much headroom for improvement (as reflected in the task-clock measurements).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D152834/new/

https://reviews.llvm.org/D152834