What does “perf interrupt took to long” mean?

Wifi problems…

So, I’m having a problem with my laptop. When I’m using the “TelenetWiFree” connection, I get disconnected after a certain amount of time, and for some reason I cannot reconnect until I restart my computer. Toggling the hardware Wifi kill-switch, which lets you disable and enable the power to the wifi hardware, does not resolve the problem. After re-enabling the hardware, the wifi doesn’t seem to come back again. Only a reboot makes the Wifi work again…

The “TelenetWiFree” Wifi doesn’t play well with all the computers we have, three Ubuntu laptops and one Chromebook, but it seems particularly wonky with my computer.  I had some free time, so I started digging into the problem.

Who watches the watchmen? It seems the kernel does…

In the dmesg output, I found the following line:

perf interrupt took too long (2528 > 2500), lowering kernel.perf_event_max_sample_rate to 50000

This doesn’t seem right, maybe this is the source of the problem! Let’s do some digging:

  • Perf is a Linux Kernel performance monitor.
  • Perf uses Non-Maskable Interrupts. This basically means Perf can tell the cpu “Pauze whatever you’re doing now and let me do something”. This allows perf to have a “watchdog” functionality where it can monitor even the most critical processes and interrupts.

With great power comes great responsibility. Perf can hang your computer by constantly pauzing everything. To make sure this won’t happen, the kernel itself monitors perf.  When it decides perf is pauzing too long, it tells perf to do a little bit less. That’s basically what that dmesg line means. The kernel told perf to do a little bit less. Does it have anything to do with the Wifi problem? Probably not… But at least I learned something: The kernel watches the watchmen…

Additional sources:

Leave a Reply

Your email address will not be published. Required fields are marked *