On 12/21/17 2:02 PM, Keith Busch wrote: > On Thu, Dec 21, 2017 at 01:53:44PM -0700, Jens Axboe wrote: >> Turns out that wasn't what patch 2 was. And the code is right there >> above as well, and under the q_lock, so I guess that race doesn't >> exist. >> >> But that does bring up the fact if we should always be doing the >> nvme_process_cq(nvmeq) after IO submission. For direct/hipri IO, >> maybe it's better to make the submission path faster and skip it? > > Yes, I am okay to remove the opprotunistic nvme_process_cq in the > submission path. Even under deeply queued IO, I've not seen this provide > any measurable benefit. I haven't either, but curious if others had. It's mostly just extra overhead, I haven't seen it provide a latency reduction of any kind. -- Jens Axboe