On 12/6/18 7:06 PM, Jens Axboe wrote: > On 12/6/18 6:58 PM, Mike Snitzer wrote: >>> There is another way to fix this - still do the direct dispatch, but have >>> dm track if it failed and do bypass insert in that case. I didn't want do >>> to that since it's more involved, but it's doable. >>> >>> Let me cook that up and test it... Don't like it, though. >> >> Not following how DM can track if issuing the request worked if it is >> always told it worked with BLK_STS_OK. We care about feedback when the >> request is actually issued because of the elaborate way blk-mq elevators >> work. DM is forced to worry about all these details, as covered some in >> the header for commit 396eaf21ee17c476e8f66249fb1f4a39003d0ab4, it is >> trying to have its cake and eat it too. It just wants IO scheduling to >> work for request-based DM devices. That's it. > > It needs the feedback, I don't disagree on that part at all. If we > always return OK, then that loop is broken. How about something like the > below? Totally untested right now... > > We track if a request ever saw BLK_STS_RESOURCE from direct dispatch, > and if it did, we store that information with RQF_DONTPREP. When we then > next time go an insert a request, if it has RQF_DONTPREP set, then we > ask blk_insert_cloned_request() to bypass insert. > > I'll go test this now. Passes the test case for me. -- Jens Axboe
