On 20/02/2020 23:31, Jens Axboe wrote: > For poll requests, it's not uncommon to link a read (or write) after > the poll to execute immediately after the file is marked as ready. > Since the poll completion is called inside the waitqueue wake up handler, > we have to punt that linked request to async context. This slows down > the processing, and actually means it's faster to not use a link for this > use case. > > We also run into problems if the completion_lock is contended, as we're > doing a different lock ordering than the issue side is. Hence we have > to do trylock for completion, and if that fails, go async. Poll removal > needs to go async as well, for the same reason. > > eventfd notification needs special case as well, to avoid stack blowing > recursion or deadlocks. > > These are all deficiencies that were inherited from the aio poll > implementation, but I think we can do better. When a poll completes, > simply queue it up in the task poll list. When the task completes the > list, we can run dependent links inline as well. This means we never > have to go async, and we can remove a bunch of code associated with > that, and optimizations to try and make that run faster. The diffstat > speaks for itself. So, it piggybacks request execution onto a random task, that happens to complete a poll. Did I get it right? I can't find where it setting right mm, creds, etc., or why it have them already. -- Pavel Begunkov
