On 2/21/20 6:51 AM, Pavel Begunkov wrote: > 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. Not a random task, the very task that initially tried to do the receive (or whatever the operation may be). Hence there's no need to set mm/creds/whatever, we're still running in the context of the original task once we retry the operation after the poll signals readiness. -- Jens Axboe
