3 ms·

So long as you have multiple cores, you can make it so that userland and the kernel are on different cores with nothing else on them. You can also disable inter

So long as you have multiple cores, you can make it so that userland and the kernel are on different cores with nothing else on them. You can also disable interrupts and just spin continuously both the user and kernel thread. No context switches ever needs to occur.

rektide 4y ago
Are you proposing giving up a core or more of your system to kernel- and moving your data between cores to ship it!- as a win? There's some scenarios where I can picture that being a win, where ultra-low latency compute is key but higher latency is fine- but this technical possibility doesnt general excite me. We may technically be at 100% no context switching, but we did kill 1/8th of our cores or whatever & stress the fabric a lot more, just to satisfy a technical constraint we set up that sounds good but is actually foolish to ask for. Going totally userland is probably smarter. Go all in on SPDK or DPDK (storage/networking). You'll need dedicated networking for the app. In general though, I think your top post was 90% right, and that's good enough, and right now hunting for 100% is a mis-goal.
- mgaunard 4y ago
  Using DPDK not only requires dedicating one core to it, but also very often dedicating the NIC to your app. It's also a very heavyweight and complex framework, and disables all kinds of security. io_uring is a compromise with a lot of advantages over that, and can be configured in different ways depending on how hard you want to optimize things.
  - rektide 4y ago
    I already mentioned the dedicated nic in DPDK. I very much agree io_uring is a great way to go & it was a good mention. But you mischaracterized it at the start & dont acknowledge that at all.
    - mgaunard 4y ago
      I didn't. io_uring allows to remove context switching entirely. That is a factual statement.
      - rektide 4y ago
        If you give up external cores, and make your fabric soak the traffic. The first alone is probably in almost all cases worse than using it and allowing context switching, then it gets worse. This is a parade of shitty disingenine crappy posting, that favors pathetic minor technicalities over the main use & actuality. Shame on you. I was trying to inform a little bit while 90% agreeing & you have brought confusion & misdirection at every turn. Seriously bad mojo dude, just awful. Almost no users will experience what you describe. It's still phenomenally good & great, excellent, a world better, but you are still using a 0.001% case, a technical possibility, to say you arent wrong, while admitting nothing, no caveats, to the 99.999% who wont experience what you are promosing. Kill your insane ego & be reasonable, think of all the people you are misleading just a little bit. If you seriously think io_uring completely supplants any and all reason for projects like kernel-wasm, I continue to disagree. I'd agree that io_uring captures a huge amount of the potential value, makes things much better. But there's still barriers that get crossed in io_uring & considering other options, in my humble view, is interesting. I have seen zero willingness on your side to entertain any such possibility.
        mgaunard 4y ago
        You're the one derailing the thread. I made a factual statement that is true. You argued it wasn't. I explained how it was true. Then you keep insisting with "but [...]" that are all irrelevant to the problem that this solution addresses. Being in the kernel alone doesn't remove interrupt-driven context switching, or being scheduled out by other kernel threads. Those are all completely orthogonal concerns, which can all be fixed without needing to put more user code in the kernel.
        rektide 4y ago
        The single threaded example I made is exactly the counter I made to this kind of narrow-minded disregard. Yeah there are interrupts happening. But whether io has to bridge the user/kernel barrier is still the main question here, and io_uring reduces but emphatically does not free us from that, it simply defers/batches/reduces the number of sys-calls. You seem unwilling in extreme to recognize this, and I don't get why you falsify your statements again and again to resist this, with your reliance on 0.001% technical possibilities almost no user would experience to justify your essentially irrational & misleading claims. You still haven't shown any compromise. I think almost no one would agree with you. io_uring is great, but as much as you dodge around the fact, there's still a kernel/user barrier, and there are systems like kernel-wasm or DPDK that keep processing on one side or the other, and as much as you for some asinine reason or simply personal failing, you are unable to admit that obvious clear & essential advantage. > I didn't. io_uring allows to remove context switching entirely. That is a factual statement. If you use io_uring, there is more kernel work than there otherwise would be. Work must transit the user/kernel barrier. And this has a cost, which can be avoided by other schemes. Simple as that. Fact. Stop throwing smoke bombs & be real. Can you show even any recognition what-so-ever, any attempt to acknowledge a single statement I've made (as I have done yours), rather than blow up every single thing I've said? It seems not. This seems like enormously bad faith posting, not done in the spirit of finding out & discussing.

rektide 4y ago

Are you proposing giving up a core or more of your system to kernel- and moving your data between cores to ship it!- as a win? There's some scenarios where I can picture that being a win, where ultra-low latency compute is key but higher latency is fine- but this technical possibility doesnt general excite me. We may technically be at 100% no context switching, but we did kill 1/8th of our cores or whatever & stress the fabric a lot more, just to satisfy a technical constraint we set up that sounds good but is actually foolish to ask for. Going totally userland is probably smarter. Go all in on SPDK or DPDK (storage/networking). You'll need dedicated networking for the app. In general though, I think your top post was 90% right, and that's good enough, and right now hunting for 100% is a mis-goal.

mgaunard 4y ago
Using DPDK not only requires dedicating one core to it, but also very often dedicating the NIC to your app. It's also a very heavyweight and complex framework, and disables all kinds of security. io_uring is a compromise with a lot of advantages over that, and can be configured in different ways depending on how hard you want to optimize things.
- rektide 4y ago
  I already mentioned the dedicated nic in DPDK. I very much agree io_uring is a great way to go & it was a good mention. But you mischaracterized it at the start & dont acknowledge that at all.
  - mgaunard 4y ago
    I didn't. io_uring allows to remove context switching entirely. That is a factual statement.
    - rektide 4y ago
      If you give up external cores, and make your fabric soak the traffic. The first alone is probably in almost all cases worse than using it and allowing context switching, then it gets worse. This is a parade of shitty disingenine crappy posting, that favors pathetic minor technicalities over the main use & actuality. Shame on you. I was trying to inform a little bit while 90% agreeing & you have brought confusion & misdirection at every turn. Seriously bad mojo dude, just awful. Almost no users will experience what you describe. It's still phenomenally good & great, excellent, a world better, but you are still using a 0.001% case, a technical possibility, to say you arent wrong, while admitting nothing, no caveats, to the 99.999% who wont experience what you are promosing. Kill your insane ego & be reasonable, think of all the people you are misleading just a little bit. If you seriously think io_uring completely supplants any and all reason for projects like kernel-wasm, I continue to disagree. I'd agree that io_uring captures a huge amount of the potential value, makes things much better. But there's still barriers that get crossed in io_uring & considering other options, in my humble view, is interesting. I have seen zero willingness on your side to entertain any such possibility.
      - mgaunard 4y ago
        You're the one derailing the thread. I made a factual statement that is true. You argued it wasn't. I explained how it was true. Then you keep insisting with "but [...]" that are all irrelevant to the problem that this solution addresses. Being in the kernel alone doesn't remove interrupt-driven context switching, or being scheduled out by other kernel threads. Those are all completely orthogonal concerns, which can all be fixed without needing to put more user code in the kernel.
        rektide 4y ago
        The single threaded example I made is exactly the counter I made to this kind of narrow-minded disregard. Yeah there are interrupts happening. But whether io has to bridge the user/kernel barrier is still the main question here, and io_uring reduces but emphatically does not free us from that, it simply defers/batches/reduces the number of sys-calls. You seem unwilling in extreme to recognize this, and I don't get why you falsify your statements again and again to resist this, with your reliance on 0.001% technical possibilities almost no user would experience to justify your essentially irrational & misleading claims. You still haven't shown any compromise. I think almost no one would agree with you. io_uring is great, but as much as you dodge around the fact, there's still a kernel/user barrier, and there are systems like kernel-wasm or DPDK that keep processing on one side or the other, and as much as you for some asinine reason or simply personal failing, you are unable to admit that obvious clear & essential advantage. > I didn't. io_uring allows to remove context switching entirely. That is a factual statement. If you use io_uring, there is more kernel work than there otherwise would be. Work must transit the user/kernel barrier. And this has a cost, which can be avoided by other schemes. Simple as that. Fact. Stop throwing smoke bombs & be real. Can you show even any recognition what-so-ever, any attempt to acknowledge a single statement I've made (as I have done yours), rather than blow up every single thing I've said? It seems not. This seems like enormously bad faith posting, not done in the spirit of finding out & discussing.