On 12/27/18 6:57 AM, Christoph Hellwig wrote: > On Fri, Dec 21, 2018 at 12:22:33PM -0700, Jens Axboe wrote: >> If an application sets IOCTX_FLAG_SCQTHREAD, the io_context gets a >> single thread backing. If used with buffered IO, this will limit >> the device queue depth to 1, but it will be async, IOs will simply >> be serialized. >> >> Or an application can set IOCTX_FLAG_SQWQ, in which case the io_context >> gets a work queue backing. The concurrency level is the mininum of >> twice the available CPUs, or the queue depth specific for the context. >> For this mode, we attempt to do buffered reads inline, in case they are >> cached. So we should only punt to a workqueue, if we would have to block >> to get our data. > > I'm really worried about having this code present twice. Do we have > strong use cases for both? Can't we emulate IOCTX_FLAG_SCQTHREAD good > enough with a workqueue without concurrency management? A work item is not a good fit for this. If we want the polled submission, which I think is pretty nifty, then you need a higher context than a wq item that comes and goes. -- Jens Axboe
