Hey there..

I have implementet Derek Molloys Loadable Kernel Module (see listing 4). It uses a Kernel Module to register a kernel interrupt on a GPIO rising edge. So every time there is a rising edge on a certain GPIO-pin, an interrupt (ISR) runs. The only thing happening in the interrupt, is counting up an integer. I'm running debian on the beaglebone (Linux beaglebone 3.8.13-bone47).

I put a square wave signal onto the GPIO, causing the interrupts to trigger with a certain frequency. If I turn the frequency up to somewhere above 10kHz, the processor freezes. I don't expect the the processor to be able to follow up to this pace, but I expect the load to be visible by the "top" command. Here is what I see:
http://i.imgur.com/Ar7nwu5.png

This measurement is taken with 10 kHz kernel interrupts running, but i still only get:

%Cpu(s): 0.0 hi

"hi" is defined as: "time spent servicing hardware interrupts" in man top
How can that be? How can i measure the impact the kernel interrupt has on the CPU's idletime?

My guess is that something else is happening. 10 kHz is not fast enough to put any load on the CPU. Most likely you are freezing the first time that your interrupt overlaps with a previous one. Check your code.

1 members found this post helpful.

What should I look for in my code? I'm just attaching an interrupt to a GPIO-event from gpio.h, and then having a really simple ISR counting a variable up.
So, say I solve the problem in the code, do you then know how to measure the modules impact on the CPU-load?
The module isn't running in a thread, so I guess I shouldn't be visible on top?

The load will not be visible on "top." Since a kernel module is "part of the kernel," all interrupt-processing is part of kernel overhead.

Everything that you describe, though, "is trivial." Therefore, undoubtedly you are mis-reading something here ... interpreting the symptoms that you see "wrongly."

"10,000 times a second" is no big deal for a CPU that executes hundreds of millions of ops per second, therefore there is a very strong probability that you are doing something wrong in your code or, much(!) more likely, in whatever userland program is interacting with your module's interface.

When you say, "the processor freezes," what exactly do you mean and exactly how do you know? There's an excellent chance that it is the (graphic?) user interface that is freezing. You might well find that Ctrl+Alt+2 or somesuch brings you to a terminal screen, even when you think the machine is "frozen." (Another Ctrl+Alt+# sequence should return you to the GUI.) If this is the case, then the problem is not in the kernel at all, but in userland.

I have stripped the IRQ function (ISR) down even further. Now it is like this:

Nothing happens when it is handling the interrupt.. So the freeze can't occur due to multiple simultaneous interrupts trying to access a shared variable.

I'm not running any GUI, I'm running it directly through the commandline. I have the beaglebone connected to my pc, via a USB-UART cable, so PuTTY is the most graphic user interface I get. The same happens when I connect via ethernet. I'm not running any other userland processes, as far as I know. When I run top, top it selves is the most demanding process.
By 'freeze' I mean: I have the kernel module inserted, when I turn the interrupt frequency up to somewhere around 10kHz, I get no response in PuTTY when I press the return key, then when I stop the interrupts from occuring, I get the responses delayed.

After this happens, I get the following messages:


I'm running the LKM with a kboject, in order to access the device from userland, maybe this is part of the reason?

Now that I know that I can't use top to meassure the impact the kernel interrupts has on the cpu load, do you then know any other method to measuring this? I wanted to use mpstat, but it seems that it doesn't come with "Linux beaglebone 3.8.13-bone47".

Sorry, if my langauge isn't always "correct", I'm new to this environment..

So I figured out that mpstat is part of the sysstat package. So when I use mpstat and iostat (also part of sysstat) to measure the impact of the kernel interrupt on the CPU-load, I still don't see any numbers changing before processor freezes.

I'm I going about this the wrong way? Is it even possible to measure kernel interrupts impact on CPU-load?

"The Processor" does not "freeze."

Something is causing your user interface to freeze, or something is causing the system-at-large to be unable to service processes and threads.

There is an enormous difference between the two. Please describe the user-environment that you are using when you conclude that "the computer 'freezes.'" (Exactly(!) how do you know?)

Of one thing I am quite sure: "10 kiloHertz" is not(!) "a load" for a CPU that executes billions of operations per second. (In fact, this is a frequency that you could easily hear.)

I suspect that you are "barking up the wrong tree" here because you have a fundamental mis-conception as to the fundamental nature of the actual problem. ("Show of hands, please, of how many other people this same thing has happened to?" And we all said, "d'oh!", did we not??)

You're dealing with a bug that is somehow standing in the way of your ability to identify the true nature of what the bug is . . .

Try booting your Linux in single-user mode and trying again. (Use su username to pass from "all-powerful root mode to that of "an ordinary user," then cd to that user's home directory ...) (Now, you are "your same old non-privileged self," but, "there is nothing else here.")

I'm not running on a traditional PC! It's running on a Beaglebone Black, an embedded processor, running "Linux beaglebone 3.8.13-bone47". I don't have a graphical user interface. I'm communicating with the Beaglebone from my Windows PC, thourh a USB cable using PuTTY. I get the same behavior whether I'm running as a root or as my "non-privileged"-used.

I guess knowing the interrupt frequency itselves isn't enough to determine the CPU-load. One interrupt may cause more than one execution(very likely).
I ran the tests again, this time logged in as root. I tried different interrupt frequencies, ranging from 1Hz to 20kHz. When I hit 20kHz, PuTTY became unresponsive, nothing happened when I pressed any keys. I got the following error meassage in the terminal:
Even the small heartbeat LED connected to the processor, stopped beating. Is this evidence of a processor freeze?

During the tests, I looked at top, cpufreq-ino, mpstat and iostat at every choosen frequency, and I didnt see any significant change in any of the values between the different tests.

How can I investigate what causes the processor to freeze?
How can I measure the impact the kernel interrupts has on the CPU-load?