Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753399AbcKARBY (ORCPT ); Tue, 1 Nov 2016 13:01:24 -0400 Received: from mail-oi0-f47.google.com ([209.85.218.47]:34902 "EHLO mail-oi0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753171AbcKARAX (ORCPT ); Tue, 1 Nov 2016 13:00:23 -0400 From: Jens Axboe X-Google-Original-From: Jens Axboe Date: Tue, 1 Nov 2016 11:00:19 -0600 To: Christoph Hellwig Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: block device direct I/O fast path Message-ID: <20161101170019.GB9797@kernel.dk> References: <1477936765-8828-1-git-send-email-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1477936765-8828-1-git-send-email-hch@lst.de> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1559 Lines: 36 On Mon, Oct 31 2016, Christoph Hellwig wrote: > Hi Jens, > > this small series adds a fasth path to the block device direct I/O > code. It uses new magic created by Kent to avoid allocating an array > for the pages, and as part of that allows small, non-aio direct I/O > requests to be done without memory allocations or atomic ops and with > a minimal cache footprint. It's basically a cut down version of the > new iomap direct I/O code, and in the future it might also make sense > to move the main direct I/O code to a similar model. But indepedent > of that it's always worth to optimize the case of small, non-I/O > requests as allocating the bio and biovec on stack and a trivial > completion handler will always win over a full blown implementation. I'm not particularly tied to the request based implementation that I did here: http://git.kernel.dk/cgit/linux-block/log/?h=blk-dio I basically wanted to solve two problems with that: 1) The slow old direct-io.c code 2) Implement the hybrid polling #1 is accomplished with your code as well, though it does lack suppor for async IO, but that would not be hard to add. #2 is a bit more problematic, I'm pondering how we can implement that on top of the bio approach. The nice thing about the request based approach is that we have a 1:1 mapping with the unit on the driver side. And we have a place to store the timer. I don't particularly love the embedded timer, however, it'd be great to implement that differently. Trying to think of options there, haven't found any yet. -- Jens Axboe