On Thu, Sep 23, 2021 at 02:19:05PM +0200, Greg KH wrote:

On Tue, Sep 14, 2021 at 07:03:36PM +0000, Mehta, Sohil wrote:

quoted

Resending.. There were some email delivery issues.

On 9/13/2021 1:27 PM, Dave Hansen wrote:

quoted

User Interrupts directly deliver events to user space and are
10x faster than the closest alternative.

Thanks Dave. This is definitely more attention-grabbing than the
previous intro. I'll include this next time.

One thing to note, the 10x gain is only applicable for User IPIs.
For other source of User Interrupts (like kernel-to-user
notifications and other external sources), we don't have the data
yet.

I realized the User IPI data in the cover also needs some
clarification. The 10x gain is only seen when the receiver is
spinning in User space - waiting for interrupts.

If the receiver were to block (wait) in the kernel, the performance
would drop as expected. However, User IPI (blocked) would still be
10% faster than Eventfd and 40% faster than signals.

Here is the updated table:
+---------------------+-------------------------+
| IPC type            |   Relative Latency      |
|                     |(normalized to User IPI) |
+---------------------+-------------------------+
| User IPI            |                     1.0 |
| User IPI (blocked)  |                     8.9 |
| Signal              |                    14.8 |
| Eventfd             |                     9.7 |
| Pipe                |                    16.3 |
| Domain              |                    17.3 |
+---------------------+-------------------------+

Relative is just that, "relative".  If the real values are extremely
tiny, then relative is just "this goes a tiny tiny bit faster than what
you have today in eventfd", right?

So how about "absolute"?  What are we talking here?

And this is really only for the "one userspace task waking up another
userspace task" policies.  What real workload can actually use this?

Also, you forgot to list Binder in the above IPC type.

And you forgot to mention that this is tied to one specific CPU type
only.  Are syscalls allowed to be created that would only work on
obscure cpus like this one?

thanks,

greg k-h