FAQ

FAQ

1. Which architectures are supported?

LIKWID supports a range of x86 CPU architectures but likely not all. We concentrated the development effort on Intel and AMD machines. Almost all architecture code is tested. For a list of architectures see section Architectures or call likwid-perfctr -i. With LIKWID 5.0 the support for ARM and POWER architectures was added. Not all features are provided for all types of CPUs, e.g. manipulating hardware prefetchers is currently only available on a range of Intel systems. With LIKWID 5.0 also experimental support for Nvidia GPUs was added.

2. Are all hardware events supported?

LIKWID offers almost all events that are defined in the Intel® Software Developer System Programming Manual, the Intel® Uncore programming guides and the AMD® BIOS and Kernel Developer’s Guides, the ARM documentation and the documentation of IBM POWER processors. Some may be missing caused by special handling likely with additional registers or PEBS/IBS usage. But, LIKWID also provides some events that are not documented, either derived from previous architectures which are close to each other (Intel SandyBridge and IvyBridge for example). Sometimes they provide even more accurate results as the documented ones but there is no guarantee that they work. Others are events combining multiple sub-events, like all valid umask bits enabled (.e.g. *_ALL events).

3. Does LIKWID support Intel's PEBS, AMD's IBS or other special sampling interfaces?

No, PEBS is an interface that must be initialized at kernel level. Same for IBS. Since LIKWID is a user-space tool, there is no possibility to maintain PEBS. Update: With the perf_event backend, it would be possible but there are currently no plans to support it.

4. Which unit does LIKWID use internally for B, kB, MB, GB?

As the units imply, you get from one unit to the other by multiplying or dividing it by 1000. E.g. 1kB = 1000B. There is no kiB or MiB possible by now. For likwid-perfctr you can create your own custom performance groups with 2-based units.

5. Does LIKWID support power capping (Intel only)?

No, by now LIKWID does not support limiting the power consumption of your machine using the RAPL interface. We added some functions but they are not exported because they need to be rechecked.

6. Is LIKWID case-sensitive?

Yes, all strings are case-sensitive. The only exception are the event options, they are case-insensitive. For upcomming versions we change to case-insensitive for all string parsing where possible.

7. I have given multiple eventsets on the command line but the values are too low? Are they multiplexed?

LIKWID does not support multiplexing of eventsets. It rotates through its eventset list and measures each for a specific amount of time. The output contains the results of all measurements of that eventset, no interpolation to the complete runtime is done. Since most other tools that support multiplexing use linear interpolation, you can scale the results yourself with (1.0 - (measurement_time/all_time)) * result. As you can see, the calculation is pretty simple, but it introduces a high degree of inaccuracy. You cannot know if the operations that were performed during the measurement of the eventset are similar to the operations that were done when measuring another eventset. As a recommendation, perform the interpolation only with Marker API measurements where you know what the application does.

8. Are there plans to port LIKWID to other operating systems?

We do not really plan to port LIKWID to other operating systems. We come from the HPC world and there the main operating systems base on the Linux kernel. Other operating systems might not even provide fundamental functions required by LIKWID like pinning application threads to a specific CPU core.

9. Are there plans to port LIKWID to other CPU architectures?

For the CPU side, there are currently no further CPU architectures on the list. For accelerators, we have AMD GPUs, Intel Xe GPUs and NEC Tsubasa on the list but time is limited.

10. Do you plan to introduce a graphical frontend for LIKWID?

No, we do not! That's out of scope of LIKWID.

11. Why does the startup of likwid-perfctr take so long?

In order to get reliable time measurements, LIKWID must determine the base clock frequency of your CPU. This is done by a measurement loop that takes about 1 second. You can avoid the measurement loop by creating a topology configuration file with likwid-genTopoCfg.

12. What about the security issue found with the MSR device files (CVE-2013-0268)? Can someone use the access daemon to exploit this

No it is not possible. At the current state, the access daemon only allows accesses to performance counter MSRs and not to MSRs like SYSENTER_EIP_MSR that are used in the exploit. Consequently, the access daemon cannot be used to exploit the security issue CVE-2013-0268.

13. I get messages like "Counter register FOO not supported or PCI device not available", what does it mean?

Every time an event set is added to LIKWID, it checks whether the registers are accessible. If not, such a message is printed. In most cases, this is not a failure, it is just informing you that the counter will be skipped later at the measurements. It happens more often with the predefined performance groups because they are created for a maximally equipped machine. If your system has e.g. less memory channels than the maximal possible, not all MBOX registers will work but the counts will be valid because the counts of the non-existant register are commonly handled by another register.

14. Likwid reports something like 'ERROR: The selected register XYZ is in use'. What causes this and is the -f/--force option safe?

Some time ago, Intel release a document Intel PMU sharing guide which lists some checks that should be performed before programming the hardware performance counters. Starting with commit 8efa0ec46a30438e1b85eac3ba31ebe0b7a03303 LIKWID now checks the counters and exits if one of the selected counters is in use. When you set on command line -f or --force or set the environment variable LIKWID_FORCE, LIKWID ignores the already running counter and clears it. On Linux system this commonly occurs for the FIXC0 which is used by the Linux kernel in the NMI watchdog. Until now we havn't seen problems clearing the FIXC0 counter although used by the NMI watchdog. If you are not sure about that, you can deactivate the NMI watchdog with sysctl -w kernel.nmi_watchdog=0 until reboot or instantly by writing kernel.nmi_watchdog = 0 into /etc/sysctl.conf.

15. I want to help, were do I start?

The best way is to talk to us at the mailing list or in the development chat. There are a bunch of small work packages on our ToDo list that can be used as a good starting point for learning how LIKWID works. If you are not a programmer but you have a good idea, let us know and we will discuss it.

16. I want to measure memory traffic on my Intel desktop-class system (i3, i5, i7, i9) but LIKWID is only reporting '-' as result. What can I do?

The reason might be that the relevant device cannot be opened. If you run likwid-perfctr -V 1 ... and you get messages like DEBUG - [checkAccess:228] WARNING: The device for counter MBOX0C1 does not exist, try adding iomem=relaxed to your Linux boot options (e.g. in grub.conf). Also make sure that SecureBoot is disabled in the BIOS of your system. For more information, see issue 327

17. What is the difference between LIKWID and PAPI?

The main difference is the measurement method. PAPI works on software process/thread basis, so you tell it to start a measurement and independent where the process runs, PAPI (or in reality perf_event in the kernel) follows the process, thus is independent of the HW threads. At least that's the default mode of PAPI, it probably has much more features. LIKWID, on the other hand, works on hardware threads and has no clue about application processes. LIKWID uses only a very limited set of kernel features (as long as you don't use the perf_event backend). LIKWID measures, for example, all applications running on hwthread X. PAPI would measure application Y on any hwthreads.

18. Why is the groups called L2 despite measuring the traffic between L1 and L2 cache? Same for the L3 group.

The reason for this naming is caused by the way of thinking in our group. We virtually take the perspective of the executing unit(s). So if the execution unit needs data from the L2 cache, we are interested in the data traffic between L1 and L2 cache. Same for the L3 cache where LIKWID measures the data between L2 and L3 cache.

19. Can LIKWID be used in virtualized environments?

In general, LIKWID runs in all Linux-like environments but the feature set might be reduced. While tools like likwid-topology and likwid-pin do not require any access to hardware registers, others rely completely on these registers (information registers, hardware performance counter, ...) like likwid-perfctr. Builds with ACCESSMODE=accessdaemon are probably not working in virtualized environments. Sometimes, you might be lucky with ACCESSMODE=perf_event but it depends on the combination of Host-OS, Guest-OS and virtualization layer. In most cases, it does not work!

20. Can LIKWID be used in Windows Subsystem for Linux (WSL)?

It was never tested but it is likely to not work. LIKWID could be ported to Windows and there was already an attempt some years ago but there are no plans to try again.

21. Why is my syslog filled with messages like 'msr: Write to unrecognized MSR 0xXXX by likwid-accessD (pid: YYYY).'?

With recent Linux kernel versions (at least 5.11+), the security mechanism were enhanced, mostly due to hardware vulnerabilities. Moreover, the Linux kernel developers have the opinion that MSRs should only be accessed by the kernel and user-space tools should use proper kernel interfaces. LIKWID uses the msr kernel module provided by the Linux kernel developers which we see as a proper interface. All LIKWID tools are written with care to do only valid operations on the registers, so from our point of view, these messages can be ignored.