Re: [RFC PATCH 00/13] x86 User Interrupts support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux