I have a 1Khz signal (from an external FPGA) connected to the GPIO3.
The problem is the CPU usage of this poll(2) on GPIO3 IRQ signal is ~10% Total CPU
The code is from the example: source code 3
this is my code:
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
#include <poll.h>
int main(int argc, char *argv[]){
int fd;
char value;
struct pollfd poll_gpio;
poll_gpio.events = POLLPRI;
// export GPIO
fd = open ("/sys/class/gpio/export", O_WRONLY);
write (fd, "3", 1);
close (fd);
// configure as input
fd = open ("/sys/class/gpio/gpio3/direction", O_WRONLY);
write (fd, "in", 2);
close (fd);
// configure interrupt
fd = open ("/sys/class/gpio/gpio3/edge", O_WRONLY);
write (fd, "rising", 6); // configure as rising edge
close (fd);
// open value file
fd = open("/sys/class/gpio/gpio3/value", O_RDONLY);
poll_gpio.fd = fd;
poll (&poll_gpio, 1, -1); // discard first IRQ
read (fd, &value, 1);
// wait for interrupt
while (1){
poll (&poll_gpio, 1, -1);
if ((poll_gpio.revents & POLLPRI) == POLLPRI){
lseek(fd, 0, SEEK_SET);
read (fd, &value, 1);
usleep (50);
// printf("Interrupt GPIO val: %c\n", value);
// break;
}
}
close(fd); //close value file
return EXIT_SUCCESS;
}
my uname -a is:
*Linux colibri-imx6 4.9.84-rt62+gb2a7f2f #1 SMP PREEMPT RT Mon Jun 25 15:44:22 CEST 2018 armv7l GNU/Linux*
the program is called “tdxgpio”
and the htop output is:
You are using a Preempt RT Kernel and you are running the application tdxxgpio at high priority. Usually with RT Kernel the delay between two events is deterministic to a certain level but the Cpu usage is higher.
You should find the actual frequency of the CPU which should vary with load, then you will know more about what 10% of cpu load really means.
For reducing the cpu load, you could also increase the sleep time.
Moreoever, what is your application? What are your trying to do with this polling.
Hi Jaski,
I have the same result in a Real time thread running with SCHED_FIFO and priority= -95
The sleeping time of 50usec is for example. The result is the same also with sleeping time of 400usec.
In the thread I make a reading/writing to an FPGA via SPI.
And, setting up another GPIO when poll return, doing some things and setting down before return to the poll, I see with the oscilloscope a delay of 200usec between my reference clock and the other GPIO. But dhis dalay have a jitter of +/- 50 usec.
ret = write (pthrd_data->fd_sig, "1", 1);
TransferDataToFPGA (pthrd_data->fd_spi);
ret = write (pthrd_data->fd_sig, "0", 1);
Hi Jaski, I have the same result in a Real time thread running with SCHED_FIFO and priority= -95
The sleeping time of 50usec is for example. The result is the same also with sleeping time of 400usec. In the thread I make a reading/writing to an FPGA via SPI.
And, setting up another GPIO when poll return, doing some things and setting down before return to the poll, I see with the oscilloscope a delay of 200usec between my reference clock and the other GPIO. But dhis dalay have a jitter of +/- 50 usec
So this means, the CPU needs 10% of his time to do the tasks in while loop. Is there any issue with that? Could you find out the cpu frequncy, when the application tdxgpio is running?
Jaski, after setting the cpus scaling governor to “performance”, I have a better response from the system, reduced delay (~30uSec vs. 200) and less jitter.
The 10% of CPU time (read from htop) remain.
But I need to better understand what cpu time column really means because single core percentuals on top of the HTOP windows sometimes are smaller or higher than 10%.
7% is not that much. You are switching the GPIO every 1ms. So if we take 10% for the sake of simplicity, this means during 100us, the CPU is doing the task of while loop. This whole task time depends also from the GPIO Bus, which is not working at the same frequency as the CPU.
Anyway, 7% is not much. CPU usage about 70% or more would be much.