On 10/7/22 10:07 AM, Linus Torvalds wrote: > On Mon, Oct 3, 2022 at 7:18 AM Jens Axboe <axboe@xxxxxxxxx> wrote: >> >> - Series that adds supported for more directly managed task_work >> running. This is beneficial for real world applications that end up >> issuing lots of system calls as part of handling work. > > While I agree with the concept, I'm not convinced this is done the > right way. > > It looks very much like it was done in a "this is perfect for > benchmarks" mode. > > I think you should consider it much more similar to plugging (both > network and disk IO). In particular, I think that you'll find that > once you have random events like memory allocations blocking in other > places, you actually will want to unplug early, so that you don't end > up sleeping with unstarted work to do. > > And the reason I say this code looks like "made for benchmarks" is > that you'll basically never see those kinds of issues when you just > run some benchmark that is tuned for this. For the benchmark, you > just want the user to control exactly when to start the load, because > you control pretty much everything. > > And then real life happens, and you have situations where you get > those odd hiccups from other things going on, and you wonder "why was > no IO taking place?" > > Maybe I'm misreading the code, but it looks to me that the deferred > io_uring work is basically deferred completely synchronously. > > I've pulled this, and maybe I'm misreading it. Or maybe there's some > reason why io_uring is completely different from all the other > situations where we've ever wanted to do this kind of plugging for > batching, but I really doubt that io_uring is magically different... I'll try and address these separately. It's interesting that you suspect it's made for benchmarks. In practice, this came about from very much the opposite angle - benchmarks were fine, but production code for Thrift was showing cases where the io_uring backend didn't perform as well as the epoll one. Dylan did a lot of debugging and head scratching here, because it wasn't one of those "let's profile and see what it is - oh yep, this needs to be improved" kind of cases. Benchmark are easy because they are very much targeted - if you write something that tries to behave like thrift, then it too will perform fine. One of the key differences is that production code actually does a bunch of things when processing a request, issuing other system calls. A benchmark does not. When the backend issues a receive and no data is available, an internal poll trigger is used to know when we can actually receive data. When that triggers, task_work is queued to do the actual receive. That's considered the fast part, because it's basically just copying the data. task_work is tied to exiting to userspace, which means that basically anything the backend does that isn't strict CPU processing will end up flushing the task_work. This really hurts efficiencies at certain rates of load. The problem was worse when task_work actually triggered a forced kernel enter/exit via TWA_SIGNAL doing an IPI to reschedule if it was running in userspace, but it was still an issue even with just deferring it to be run whenever a transition happened anyway. I do agree that you have a point on it being somewhat similar to plugging in the sense that you would probably want this flushed if you get scheduled out anyway. For production loads where you end up being resource constrained (not a rare occurence...), we want them run before putting the task to sleep. We'll look into making a tweak like that, it seems like the right thing to do. I'm sure Dylan can chime in on the above too once he's back, to add some more data to this change. -- Jens Axboe
