Is epoll efficient with devices (/ dev / event / ...)?

Question

I am working on an approximated applet process that creates a proxy virtual device (more precisely, an Xbox 360 virtual panel); I manage to create it using the uinput interface, I configured it correctly and it works fine.

To give commands to this virtual device, I read events from another real interface (in this case, the PS3 pad), and I open the real device file with these flags:

fd = open("/dev/input/event22", O_RDONLY); // open the PS3 pad 

The main loop is something like (minus error checking):

 while(run) { input_event ev = {0}; read(fd, &ev, sizeof(struct input_event)); // convert from PS3 --> Xbox 360 convert(ev); // write to the new virtual pad write(fd_virtual, &ev, sizeof(struct input_event)); } 

As you can imagine, read(fd, &ev, sizeof(struct input_event)); is a blocking call, and I would like to have some timeout for looping and checking other events / executing different code.

For these reasons, I am thinking of encapsulating the read(fd... call inside the epoll loop, so I can also get a timeout.

The question is, would it be effective to do so? By using epoll_wait, did I introduce additional delays in the current loop, which delays the responsiveness of the virtual panel?

Answer 1

By virtue of using epoll_wait, did I introduce additional delays in the current loop, thus delaying the responsiveness of the virtual panel?

Oh sure.

would it be effective to do so?

I'm sure yes, but it really depends on your definition of "effective."

What we are talking about is a human input device. What we care mainly when working with HID is latency, it should not lag behind, the response to a keystroke should be instant. What is a moment for a person? There is a good discussion there , but one argument that I like best is that at a high level track and field competition you would be disqualified for running less than 100 ms after the signal.

But this 100 ms is the time budget for the complete processing of the input signal, from pressing a key to some perceived changes in the game. There are some numbers on the Wikipedia page about input lag about how this budget is usually spent.

In any case, I think that 1 ms is absolutely safe overhead, which you can add using your proxy, and no one will notice, say, that our goal is to maximize the delay (as in the definition of "effective").

So let's say that you are satisfied with the response time from your current code. What are the changes when adding an epoll() call? Basically, you add some time to create another syscall, because now instead of one syscall get the value that you make two. So potentially this is about twice as slow as your source code (forget about the processing time difference for different system calls at the moment). But is it really that bad?

To answer this question, we need to have some estimate of what syscall overhead is. If we are too lazy to measure it ourselves, we can use some numbers from 20 years ago , some numbers of people who care about syscalls , some IPC numbers from micronuclear guys (they always care) , some fooobar.com/questions/1193102/ ... or just ask Rich and settle around the microsecond level as a safe guess.

Thus, the question boils down to the fact that the addition of some (even say 10) microseconds is noticeable during your millisecond (as in 1000 microseconds). I think not.

There is only one small possible problem when you have to go from "just add epoll() " to

loop through loop and check other events / execute different code.

You must be careful to stay within your time budget for these cycles and checks. But then again, 1 ms is probably more than enough for you here.