On 9/30/2021 9:26 AM, Stefan Hajnoczi wrote:
On Mon, Sep 13, 2021 at 01:01:19PM -0700, Sohil Mehta wrote:
+------------+-------------------------+ | 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/ev...
Yes. I have left it unmodified from the original source. But, I should have looked at it more closely.
Two things stand out:
- 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.
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