Announcement

Collapse
No announcement yet.

Linux Support For Sapphire Rapids' User Interrupts Still Awaiting Mainline

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Linux Support For Sapphire Rapids' User Interrupts Still Awaiting Mainline

    Phoronix: Linux Support For Sapphire Rapids' User Interrupts Still Awaiting Mainline

    A new feature with Intel 4th Gen Xeon Scalable "Sapphire Rapids" that hasn't been talked about too much is the new User Interrupts (UNITR) functionality. The Linux kernel support for it still also hasn't been merged but has shown promising results in patch form...

    https://www.phoronix.com/news/Linux-...ser-Interrupts

  • #2
    I'd be interested if any CPU vendor is working on synchronization primitives targeted at improving synchronization (latency) of io_uring.

    It would be nice if user space process would get notified immediately when kernel stores a response to completion queue,
    and vice versa, if kernel would get notified when a user space process puts something into submission queue.

    As far as I understand, currently both sides are polling for state updates (pls. correct me if I'm wrong).

    Comment


    • #3
      Originally posted by pkese View Post
      I'd be interested if any CPU vendor is working on synchronization primitives targeted at improving synchronization (latency) of io_uring.

      It would be nice if user space process would get notified immediately when kernel stores a response to completion queue,
      and vice versa, if kernel would get notified when a user space process puts something into submission queue.

      As far as I understand, currently both sides are polling for state updates (pls. correct me if I'm wrong).
      I may be wrong, but I believe that io_uring's performance comes from the fact that it is asynchronous.
      Notifying kernel or user space immediately makes things synchronous, which you could already achieve using old POSIX APIs.

      Am I being wrong?

      Comment


      • #4
        Originally posted by aviallon View Post

        I may be wrong, but I believe that io_uring's performance comes from the fact that it is asynchronous.
        Notifying kernel or user space immediately makes things synchronous, which you could already achieve using old POSIX APIs.

        Am I being wrong?
        No. They are still asynchronous: while kernel is handling queued requests, the user space can continue doing some other work.
        But when kernel is done with its work, user space should be able to request to be immediately notified when the results are available, rather than polling for state change.
        This could lower the latency.

        Io_uring has extremely high throughput when performing many things at once, but at the cost of higher latency.
        Some synchronization primitives (as in get notified when the work is done and do something with it immediately) could improve latency situation.

        Comment


        • #5
          Intel's oneAPI LevelZero mentions peer to peer communication. I wonder if they intend to extend it to handle interrupts.

          Comment

          Working...
          X