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/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
