FAQ

1. Which architectures are supported?

   Mess currently supports x86-64 (Intel/AMD), ARM64 (AArch64), PowerPC (ppc64le), and RISC-V (rv64gcv). See Architecture Support for full details.

   GPU Support: Mess 2.0 is actively being ported to GPUs. For now, GPU support is available via the Mess 1.0 codebase in our GPU Repository.

2. Does Mess support running on Windows or macOS?

   Mess is designed for Linux environments due to its reliance on hardware performance counters (perf) and specific memory allocation APIs. macOS support is limited to compilation for development but cannot run the actual benchmark. Windows is not supported.

3. Why do I get a "Permission denied" error when running?

   This usually happens because the system locks access to hardware performance counters for security. You can temporarily allow access by running echo 0 | sudo tee /proc/sys/kernel/perf_event_paranoid or permanently by adding kernel.perf_event_paranoid = 0 to /etc/sysctl.conf.

4. Can I run Mess without root privileges?

   Yes, as long as perf_event_paranoid is set to allow user access (<= 2), you do not need root. However, changing system-wide settings like CPU frequency scaling or dropping caches will still require sudo.

5. What does the "Profiling" mode do?

   Running with --profile generates CSV files in the measuring/ folder containing detailed bandwidth and latency measurements for every test point. This is required if you want to plot the bandwidth-latency curves later. The default "plain" run only outputs a summary to the console.

6. Can I use LIKWID instead of perf?

   Yes! You can force the use of LIKWID by adding the --measurer=likwid flag. Make sure likwid-perfctr is installed and in your PATH.

   HBM Systems: On systems with High Bandwidth Memory, the versions of perf we have tested do not correctly map the CAS_COUNT events we use to the HBM registers. Instead, they map them to the MBOX counters, which report 0 when using HBM. LIKWID correctly accesses the HBM counters, which is why it is recommended for these systems. We expect this to be fixed in future perf versions.

7. Can I use Intel VTune as the measurer?

   Yes. You can force VTune by adding --measurer=vtune to mess, or --backend vtune to mess-profiler. The vtune binary must be installed and available in your PATH.

   VTune is currently an explicit backend only; it is not the default automatic choice for any architecture. It also has significantly higher interval-sampling overhead than perf or likwid, because each sample launches a VTune collection.

8. How is the "Memory Bandwidth" actually measured?

   We use hardware performance counters that directly track memory controller activity. The specific counters depend on your system architecture:

   • CAS_COUNT events: On systems with memory controllers that support it (most x86 servers), we use CAS_COUNT_RD and CAS_COUNT_WR to measure DRAM read and write transactions issued by the memory controller
   • UPI/QPI FLITS: For cross-socket bandwidth when accessing remote memory, we use UPI FLITS TXL/RXL counters to track inter-socket traffic
   • Platform-specific counters: On systems like NVIDIA Grace, we use the platform-specific counters documented by the vendor (e.g., cmem_rd_data, cmem_wr_total_bytes)
   • DRAM request counters: On some AMD platforms that don't differentiate reads from writes, we use available DRAM request counters to measure total bandwidth

   We do not estimate bandwidth from the code; we measure actual hardware activity at the memory controller level.

9. I found a bug or have a feature request, where do I report it?

   Please open an issue on our GitHub Repository or send us an email at mess@bsc.es.