Intel® Memory Latency Checker v3.5


Vish Viswanathan, Karthik Kumar, Thomas Willhalm, Patrick Lu, Blazej Filipiak, Sri Sakthivelu



An important factor in determining application performance is the time required for the application to fetch data from the processor’s cache hierarchy and from the memory subsystem. In a multi-socket system where Non-Uniform Memory Access (NUMA) is enabled, local memory latencies and cross-socket memory latencies will vary significantly. Besides latency, bandwidth (b/w) also plays a big role in determining performance. So, measuring these latencies and b/w is important to establish a baseline for the system under test, and for performance analysis.

Intel® Memory Latency Checker (Intel® MLC) is a tool used to measure memory latencies and b/w, and how they change with increasing load on the system. It also provides several options for more fine-grained investigation where b/w and latencies from a specific set of cores to caches or memory can be measured as well.



Intel® MLC supports both Linux and Windows.


  • Copy the mlc binary to any directory on your system
  • Intel® MLC dynamically links to GNU C library (glibc/lpthread) and this library must be present on the system
  • Root privileges are required to run this tool as the tool modifies the H/W prefetch control MSR to enable/disable prefetchers for latency and b/w measurements. Refer readme documentation on running without root privileges
  • MSR driver (not part of the install package) should be loaded. This can typically be done with 'modprobe msr' command if it is not already included.


  • Copy mlc.exe and mlcdrv.sys driver to the same directory. The mlcdrv.sys driver is used to modify the h/w prefetcher settings

There are two sets of binaries (mlc and mlc_avx512). One is compiled with newer tool chain to support Intel® AVX-512 instructions. The other binary supports SSE2 and AVX2 instructions. mlc_avx512 binary is a super set of mlc binary in that it supports SSE2/AVX2 as well. So, mlc_avx512 can be run on processors without support for AVX-512 also. By default AVX-512 instructions won’t be used whether the processor supports it or not unless –Z argument is specified. We recommend you start with mlc_avx512 and if your system does not have the newer versions of glibc, then you can fall back to mlc binary


HW Prefetcher Control

It is challenging to accurately measure memory latencies on modern Intel processors as they have sophisticated h/w prefetchers. Intel® MLC automatically disables these prefetchers while measuring the latencies and restores them to their previous state on completion. The prefetcher control is exposed through MSR ( and MSR access requires root level permission. So, Intel® MLC needs to be run as ‘root’ on Linux. On Windows, we have provided a signed driver that is used for this MSR access. If Intel® MLC can’t be run with root permissions, please consult the readme.pdf that can be found in the download package.


What does the tool measure

When the tool is launched without any argument, it automatically identifies the system topology and measures the following four types of information. A screen shot is shown for each.

1. A matrix of idle memory latencies for requests originating from each of the sockets and addressed to each of the available sockets

2. Peak memory b/w measured (assuming all accesses are to local memory) for requests with varying amounts of reads and writes 

3. A matrix of memory b/w values for requests originating from each of the sockets and addressed to each of the available sockets

4. Latencies at different b/w points

It also measures cache-to-cache data transfer latencies

Intel® MLC also provides command line arguments for fine grained control over latencies and b/w that are measured.

Here are some of the things that are possible with command line arguments:

  • Measure latencies for requests addressed to a specific memory controller from a specific core
  • Measure cache latencies
  • Measure b/w from a subset of the cores/sockets
  • Measure b/w for different read/write ratios
  • Measure latencies for random address patterns instead of sequential
  • Change stride size for latency measurements
  • Measure cache-to-cache data transfer latencies


How does it work

One of the main features of Intel® MLC is measuring how latency changes as b/w demand increases. To facilitate this, it creates several threads where the number of threads matches the number of logical CPUs minus 1. These threads are used to generate the load (henceforth, these threads will be referred to as load-generation threads). The primary purpose of the load-generation threads is to generate as many memory references as possible. While the system is loaded like this, the remaining one CPU (that is not being used for load generation) runs a thread that is used to measure the latency. This thread is known as the latency thread and issues dependent reads. Basically, this thread traverses an array of pointers where each pointer is pointing to the next one, thereby creating a dependency in reads. The average time taken for each of these reads provides the latency. Depending on the load generated by the load-generation threads, this latency will vary. Every few seconds the load-generation threads automatically throttle the load generated by injecting delays, thus measuring the latency under various load conditions. Please refer to the readme file in the package that you download for more details


Command line arguments

Launching Intel® MLC without any parameters measures several things as stated earlier. However, with command line arguments, each of the following specific actions can be performed in sequence:

mlc --latency_matrix

      prints a matrix of local and cross-socket memory latencies

mlc --bandwidth_matrix

      prints a matrix of local and cross-socket memory b/w

mlc --peak_injection_bandwidth

      prints peak memory b/w (core generates requests at fastest possible rate) for various read-write ratios with all local accesses

mlc --max_bandwidth

      prints maximum memory b/w (by automatically varying load injection rates) for various read-write ratios with all local accesses

mlc --idle_latency            

      prints the idle memory latency of the platform

mlc --loaded_latency          

      prints the loaded memory latency of the platform

mlc --c2c_latency

      prints the cache-to-cache transfer latencies of the platform

mlc -e          

     do not modify prefetcher settings

There are more options for each of the commands above. Those are documented in the readme file in more detail and can be downloaded 


Change Log

Version 1.0

  • Initial release 

Version 2.0

  • Support for b/w and loaded latencies added

Version 2.1

  • Launch 'spinner' threads on remote node for measuring better remote memory b/w
  • Automatically disable numa balancing support (if present) to measure accurate remote memory latencies

Version 2,2

  • Fixed a bug in topology detection where certain kernels were numbering the cpus differently. In those cases, consecutive cpu numbers were assigned to the same physical core (like cpus 0 and 1 are on physical core 0..)

Version 2.3

  • Support for Windows O/S
  • Support for single socket (E3 processor line)
  • Support for turning off automatic prefetcher control

Version 3.0

  • Support for client processors like Haswell and Skylake
  • Allocate memory based on NUMA topology. This allows Intel® MLC to measure latencies on all the numa nodes on a processor like Haswell that supports Cluster-on-Die configuration where there are 4 numa nodes on a 2-socket system. We can also measure latencies to NUMA nodes which have only memory resources without any compute resources
  • Support for measuring latencies and bandwidth to persistent memory
  • Options to use 256-bit and 512-bit loads and stores in generating bandwidth traffic
  • Support for measuring cache-to-cache data transfer latencies
  • Control several parameters like read/write ratios, size of buffer allocated, numa node to allocate memory etc on a per-thread basis

Version 3.1

  • Support for Skylake Server

Version 3.1a

  • MLC failing on some guest VMs issue fixed

Version 3.3

  • Several fixes for measuring latencies and b/w on Skylake server

Version 3.4

  • Added support for multiple numa nodes on a socket on Windows server
  • Several enhancements for measuring latencies and b/w on persistent memory
  • Changed peak_bandwidth to peak_injection_bandwidth and added --max_bandwidth option to support automatically measure the best possible bandwid

Version 3.5

  • Fixed memory leak issues that caused MLC to fail on large systems (8-socket)
  • Added option to flush cache lines to persistent memory
  •  Added option to only partially load/store cache line (loading only 16 bytes instead of entire 64 byte) to get best cache b/w


Both Linux and Windows versions of  Intel® MLC are included in the download.

For more complete information about compiler optimizations, see our Optimization Notice.


Kumar, Shivam (Intel)'s picture

Hi All,

Is the tool is capable of measuring:

CAS Latency(CL)
RAS to CAS Delay(tRCD)
RAS Precharge(tRP)
Cycle Time(tRAS)
Row Refresh Cycle Time(tRFC)
Command Rate(CR)

if not, please suggest some tool for RHEL. 

maw, abe's picture

Hello, there,

    Is there any plan to open-source mcl? Thanks


Sankewitz, Volker (Intel)'s picture


tar and gzip files are commonly used on linux but not on windows. It would be great to get a windows only download of, so that a pure windows user do not have to install additional SW for being able to untar and uzip the tgz or using linux OS to get the windows binary out of linux tgz file.

Thank you.


Hal G. (Intel)'s picture

Questions regarding this article should be posted to the forums here:

Questions posted to Articles may or may not be responded to.

Regards, Hal

Intel(R) Developer Zone Support
*Other names and brands may be claimed as the property of others.

Kim, Yongsik's picture

Does MLC v3.4 support gemini lake or not?

Junchao Z.'s picture

How is the latency defined? Is it the time to read the 200MB buffer from memory to CPU?

Vinay Y.'s picture

Hi All,

I ran exactly this command on both machine
sudo ./mlc -e -r -c3 -i2 -l128 --c2c_latency

and following are the results for different CPUs

[CPU 1]
 Intel(R) Xeon(R) Gold 6144 CPU @ 3.50GHz
 No of numa node = 1
 uname -a
   Linux cresco31 4.4.87-18.29-default #1 SMP Wed Sep 13 07:07:43 UTC 2017 (3e35b20) x86_64 x86_64 x86_64 GNU/Linux
 sudo ./mlc -e -r -c3 -i2 -l128 --c2c_latency
   Latency = 231.1 core clocks (66.0 ns)

[CPU 2]
 Intel(R) Xeon(R) CPU E5-2643 v2 @ 3.50GHz
 No of numa node = 1
 uname -a
   Linux cresco29 4.4.73-18.17-default #1 SMP Fri Jun 23 20:25:06 UTC 2017 (f462a66) x86_64 x86_64 x86_64 GNU/Linux
 sudo ./mlc -e -r -c3 -i2 -l128 --c2c_latency
   Latency = 157.6 core clocks (45.0 ns)

We can see that for newer CPU cache to cache latency has significantly increased. Does this means that new CPUs are slower in this regard?



Colin Reinhardt's picture


Is MLC only for CPU memory performance? Or, for Skylake can it also profile on-chip Intel Processor Graphics (e.g. HD 530, P530) memory subsystem?

If not, what is best/recommended way to determine peak achievable memory bandwidth values for the Intel Processor Graphics (GPU), and evaluate cache performance?

Is the best/only option VTune Amplifier XE (2017)?  Thank you, Colin

Karthik Kumar (Intel)'s picture

@Andrea P. can you please share how you are emulating persistent memory (as a numa node or as /dev/pmem?)... also how are you pointing MLC to use this emulated persistent memory for measurements?

Andrea P.'s picture

FYI, when I emulate persistent memory (pmem) on my Linux machine, mlc exits immediately without running any tests. When I plug gdb to check what crashes, I get this:

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/".
Intel(R) Memory Latency Checker - v3.1a
Command line parameters: --loaded_latency

Program received signal SIGSEGV, Segmentation fault.
0x000000000040dbf9 in ?? ()
(gdb) bt
#0  0x000000000040dbf9 in ?? ()
#1  0x0000000000401b7a in ?? ()
#2  0x00007ffff7811a40 in __libc_start_main (main=0x4018b0, argc=2,
    argv=0x7fffffffe5f8, init=<optimized out>, fini=<optimized out>,
    rtld_fini=<optimized out>, stack_end=0x7fffffffe5e8) at libc-start.c:289
#3  0x0000000000403749 in ?? ()



Add a Comment

Have a technical question? Visit our forums. Have site or software product issues? Contact support.