Announcement

Collapse
No announcement yet.

Intel Posts Initial Code For x86 User Interrupts On Linux - Shows Great Performance Potential

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

  • sinepgib
    replied
    Originally posted by Paul Frederick View Post

    Do I?
    What i mean is if Alphabet, the parent company of Google, is going to pay anyone to do anything they're going to pay people to work on their own projects. I hope that clears things up for you.
    More or less. We agree that Alphabet is not a charity and won't be making things just for the greater good (I'm guessing they don't oppose to it being a collateral at times tho), but that has nothing to do with ownership of the project. If there's commercial value for them, they'll do it. That's why they still pay for some Linux developers.
    All ermo said is, if wishful, consistent with that, except maybe the Intel whiteboxes. Writing userspace drivers for Linux that are compatible with Fuchsia is useful for them to allow a more gradual deploy and easier marketing, for example. Having the source code of the firmware they run available suits them as well (the exception being they can very well keep it to themselves and still reap the benefits).

    Leave a comment:


  • 673zz5
    replied
    This could be quite handy for an embedded system and would have been useful for some custom hardware projects I've been involved with. When I need this sort of thing I have had to e.g. write my own driver and set up ioctl() calls that wait on a condition variable so that the driver's interrupt handler can signal the condition variable and allow the ioctl() to return. The exact details are messier but that is the basic idea. The big question for me is the execution context of the interrupt callback. If its e.g. a callback from some kernel thread then there are user space actions that shouldn't be done in that context and something like a condition variable handoff to a user thread would still be needed. Even so, it looks like it would be good to have either way.

    Leave a comment:


  • Paul Frederick
    replied
    Originally posted by sinepgib View Post

    You mean Fuchsia, the one referred by ermo in the post you quoted?
    Do I?
    What i mean is if Alphabet, the parent company of Google, is going to pay anyone to do anything they're going to pay people to work on their own projects. I hope that clears things up for you.

    Leave a comment:


  • onlyLinuxLuvUBack
    replied
    is this new instruction for desktop cpu lineups too? so I would have to buy a new cpu finally after years?

    Leave a comment:


  • microcode
    replied
    Wonder if this sort of thing can be used in the context of seL4.

    Leave a comment:


  • sinepgib
    replied
    Originally posted by Paul Frederick View Post
    just made their own kernel.
    You mean Fuchsia, the one referred by ermo in the post you quoted?

    Leave a comment:


  • Paul Frederick
    replied
    Originally posted by ermo View Post
    Food for thought:

    - Imagine if Google
    just made their own kernel.

    Leave a comment:


  • Emmanuel Deloget
    replied
    Originally posted by tildearrow View Post
    Looks good, but...
    Linux is a monolithic kernel and hence most (if not all) interrupts have to go through the kernel first by design (unless I am wrong)
    This is not tied to the fact that the kernel is monolithic but to that fact that the interrupt vector (the list of entry point) is only available at ring0, because the whole operation has always been supposed to be run at ring0 (or EL1 / EL2 on arm64).

    User-space interrupts are a novelty, but I'm waiting to understand both the security model and the thread model. If any application can force an interrupt to occur in another application, this might lead to a new kind of DoS. I can see the benefits in many other situations though, especially for IPC mechanisms.

    I haven't looked at the patch yet and I hope this is not going to be an intel-only mechanism (read: it might one day be implemented on other architecture) - in which case it would have little to no interest for the broader community (most of my work in on ARM64-based hardware so...).

    Leave a comment:


  • indepe
    replied
    This might not work as one would expect (likely due to the software implementation of that patch, but I would't know if it could also be the hardware design):

    It sounds like the handler only gets invoked immediately if the targeted "task" is already in the running state. That is, not blocking and not preempted. However I'm not sure how that exactly works, this seems to require more extensive reading.

    As far as I can tell from a quick read, the benchmark seems to always use spinning for the new user-interrupts ("Keep spinning until the interrupt is received"). Whereas for eventfd it not only uses a read in blocking mode, but also the strange situation that the same eventfd is used in both directions, which means that the writer can read its own written data (its read directly follows the write), and then the benchmark checks that and has a code path that will re-write it. And apparently no comment on what effect that might have on performance numbers.

    If the benchmark uses an always spinning read, I'd think a comparison should also include an implementation that uses spinning atomic operations on shared memory, which has a good chance of being faster, I'd think. And maybe in that scenario eventfd would do better with a loop of non-blocking reads (and maybe a version that uses a different eventfd in both directions so that writers can't read their own data).

    I think the usefulness in performance terms will depend on the latency of waking a designated thread that does a kernel-blocking-wait for the next interrupt (since that seems to be how a non-spinning scenario would work), compared to the latency of a thread that does a kernel futex wait.

    Nevertheless I'd be cautiously optimistic about a possible future of this feature, hoping that these concerns are either unfounded and due to a lack of information (or reading), or that they will be resolved.
    Last edited by indepe; 13 September 2021, 07:42 PM.

    Leave a comment:


  • ermo
    replied
    Food for thought:

    - Imagine if Google paid a Rust dev to work on Linux driver infrastructure.
    - Imagine if Google paid a Linux Kernel dev to add a Linux userspace driver framework.
    - Imagine if Google developed a micro-kernel-based operating system with userspace drivers to replace their Linux-based Android OS.
    - Imagine if Google designed and built its own Intel whiteboxes for its datacenters running Linux.
    - Imagine if Google and Microsoft had each independently reached the conclusion that non-memory-safe languages (C and C++) account for about 70 percent of all registered Google and MS CVEs respectively.

    Now imagine all of the above wasn't just in your imagination. Now swallow the red pill.

    What if within a few years, Google manages to migrate large parts of their hardware to userspace Rust drivers in a way that makes them seamlessly compatible with Zircon/Fuchsia? And what if they replace parts in Zircon/Fuchsia with Rust code piecemeal?

    I find this potential future rather exciting I must admit.

    Leave a comment:

Working...
X