On 9/30/2021 9:26 AM, Stefan Hajnoczi wrote:

On Mon, Sep 13, 2021 at 01:01:19PM -0700, Sohil Mehta wrote:

quoted

+------------+-------------------------+
| IPC type   |   Relative Latency      |
|            |(normalized to User IPI) |
+------------+-------------------------+
| User IPI   |                     1.0 |
| Signal     |                    14.8 |
| Eventfd    |                     9.7 |

Is this the bi-directional eventfd benchmark?
https://github.com/intel/uintr-ipc-bench/blob/linux-rfc-v1/source/eventfd/eventfd-bi.c

Yes. I have left it unmodified from the original source. But, I should 
have looked at it more closely.

Two things stand out:

1. The server and client threads are racing on the same eventfd.
    Eventfds aren't bi-directional! The eventfd_wait() function has code
    to write the value back, which is a waste of CPU cycles and hinders
    progress. I've never seen eventfd used this way in real applications.
    Can you use two separate eventfds?

Sure. I can do that.

2. The fd is in blocking mode and the task may be descheduled, so we're
    measuring eventfd read/write latency plus scheduler/context-switch
    latency. A fairer comparison against user interrupts would be to busy
    wait on a non-blocking fd so the scheduler/context-switch latency is
    mostly avoided. After all, the uintrfd-bi.c benchmark does this in
    uintrfd_wait():

      // Keep spinning until the interrupt is received
      while (!uintr_received[token]);

That makes sense. I'll give this a try and send out the updated results.

Thanks,
Sohil