From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758172AbaKUKHE (ORCPT ); Fri, 21 Nov 2014 05:07:04 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:45778 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752189AbaKUKG6 (ORCPT ); Fri, 21 Nov 2014 05:06:58 -0500 Date: Fri, 21 Nov 2014 02:06:57 -0800 From: Christoph Hellwig To: Omar Sandoval Cc: Christoph Hellwig , linux-btrfs@vger.kernel.org, Mel Gorman , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [RFC PATCH 0/6] btrfs: implement swap file support Message-ID: <20141121100657.GD8866@infradead.org> References: <20141117154817.GA25670@infradead.org> <20141119072235.GA6541@mew> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141119072235.GA6541@mew> User-Agent: Mutt/1.5.23 (2014-03-12) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 18, 2014 at 11:22:35PM -0800, Omar Sandoval wrote: > Here's a nice little bit of insanity I put together in that direction -- > consider it a discussion point more than a patch. It does two things: > > - Uses an ITER_BVEC iov_iter to do direct_IO for swap_readpage. This makes > swap_readpage a synchronous operation, but I think that's the best we can do > with the existing interface. Note that ->read_iter for direct-io supports async I/O in general. By resurrecting some of the older attempts to do in-kernel aio this could be made async easily. > - Unless I'm missing something, there don't appear to be any instances of > ITER_BVEC | READ in the kernel, so the dio path doesn't know not to dirty > pages it gets that way. Dave Kleikamp and Ming Lei each previously submitted > patches doing this as part of adding an aio_kernel interface. (The NFS direct > I/O implementation doesn't know how to deal with these either, so this patch > actually breaks the only existing user of this code path, but in the interest > of keeping the patch short, I didn't try to fix it :) Right, we'd need to look into. Bonus points of allowing this as a zero copy read. Btw, in the long run I would much prefer killing of the current horrible swap using bmap path in favor of an enhanced direct I/O path.