Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 9 Apr 2019 02:37:17 -0700
From:   Christoph Hellwig <hch@infradead.org>
To:     Jianchao Wang <jianchao.w.wang@oracle.com>
Cc:     axboe@kernel.dk, viro@zeniv.linux.org.uk,
        linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH V2] io_uring: introduce inline reqs for
 IORING_SETUP_IOPOLL
Message-ID: <20190409093717.GA15391@infradead.org>
References: <1554787314-27179-1-git-send-email-jianchao.w.wang@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1554787314-27179-1-git-send-email-jianchao.w.wang@oracle.com>
User-Agent: Mutt/1.9.2 (2017-12-15)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Apr 09, 2019 at 01:21:54PM +0800, Jianchao Wang wrote:
> For the IORING_SETUP_IOPOLL case, all of the submission and
> completion are handled under ctx->uring_lock or in SQ poll thread
> context, so io_get_req and io_put_req has been serialized well.
> The only exception is the asynchronous workqueue context where could
> free the io_kiocb for error. To overcome this, we allocate a new
> io_kiocb and free the previous inlined one.
> 
> Based on this, we introduce the preallocated reqs list per ctx and
> needn't to provide any lock to serialize the updating of list. The
> performacne benefits from this. The test result of following fio
> command

I really don't like the idea of exposing this to userspace.  Is
there any good reason to not simply always allocate inline request
up to a certain ring size?