From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bombadil.infradead.org ([198.137.202.133]:53260 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727341AbeL0N56 (ORCPT ); Thu, 27 Dec 2018 08:57:58 -0500 Date: Thu, 27 Dec 2018 14:57:53 +0100 From: Christoph Hellwig To: Jens Axboe Cc: linux-fsdevel@vger.kernel.org, linux-aio@kvack.org, linux-block@vger.kernel.org, hch@lst.de, viro@zeniv.linux.org.uk Subject: Re: [PATCH 19/22] aio: support kernel side submission for aio with SCQRING Message-ID: <20181227135753.GE25525@infradead.org> References: <20181221192236.12866-1-axboe@kernel.dk> <20181221192236.12866-20-axboe@kernel.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181221192236.12866-20-axboe@kernel.dk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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?