From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 92BEC7F51 for ; Tue, 4 Feb 2014 12:08:53 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 6B7878F8039 for ; Tue, 4 Feb 2014 10:08:50 -0800 (PST) Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [195.92.253.2]) by cuda.sgi.com with ESMTP id lxgesUtO2YmVsbAd (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 04 Feb 2014 10:08:48 -0800 (PST) Date: Tue, 4 Feb 2014 18:08:37 +0000 From: Al Viro Subject: Re: [RFC] unifying write variants for filesystems Message-ID: <20140204180837.GJ10323@ZenIV.linux.org.uk> References: <20140119051335.GN10323@ZenIV.linux.org.uk> <20140120135514.GA21567@infradead.org> <20140201224301.GS10323@ZenIV.linux.org.uk> <52EFC271.3090205@oracle.com> <20140204124409.GG10323@ZenIV.linux.org.uk> <20140204125220.GB12440@kmo-pixel> <20140204151728.GH10323@ZenIV.linux.org.uk> <20140204172723.GA11325@lenny.home.zabbo.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com To: Kent Overstreet Cc: Jens Axboe , Christoph Hellwig , Sage Weil , Zach Brown , Mark Fasheh , xfs@oss.sgi.com, Steve French , Dave Kleikamp , Joel Becker , linux-fsdevel , Linus Torvalds , Anton Altaparmakov On Tue, Feb 04, 2014 at 09:35:06AM -0800, Kent Overstreet wrote: > > I think Kent is talking about what happens after the user addresses are > > consumed. Turning dio into more of a bio mapping and redirection engine > > would use more of the bio machinery instead of the bits that dio has > > implemented itself with state in struct dio that hangs off the bios. I > > imagine it'd still make sense to clean up the addresses/pages arguments > > that feed that engine. (And give another entry point that already has > > bios for callers like loop, etc.) > > Yeah, precisely. I think we can push the point at which pages are pinned at > least a fair but higher than it is now, and if we can do that we definitely > should be working with a generic "bag of pinned pages" struct - and much > better to use struct bio than add another one. Bios may not be perfect but > at least some of the block layer specific cruft can be gotten rid of (and > is on my todo list) How far up? I've no problem with having that done in ->direct_IO() (especially if it would take this mem_vec/mem_stream/whatever and keep the code doing actual pinning and building an array of pages outside of direct-io.c, allowing it to do different things for iovec-backed and page-array-backed variants), but I really don't like the idea of lifting that to callers of ->direct_IO(), let alone past them. If nothing else, we do *not* want to pin the entire write request, so lifting that to e.g. generic_file_aio_write() (or, worse, its callers) wouldn't make sense. _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [RFC] unifying write variants for filesystems Date: Tue, 4 Feb 2014 18:08:37 +0000 Message-ID: <20140204180837.GJ10323@ZenIV.linux.org.uk> References: <20140119051335.GN10323@ZenIV.linux.org.uk> <20140120135514.GA21567@infradead.org> <20140201224301.GS10323@ZenIV.linux.org.uk> <52EFC271.3090205@oracle.com> <20140204124409.GG10323@ZenIV.linux.org.uk> <20140204125220.GB12440@kmo-pixel> <20140204151728.GH10323@ZenIV.linux.org.uk> <20140204172723.GA11325@lenny.home.zabbo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Zach Brown , Dave Kleikamp , Steve French , Sage Weil , Linus Torvalds , Jens Axboe , Anton Altaparmakov , Mark Fasheh , linux-fsdevel , xfs@oss.sgi.com, Joel Becker , Christoph Hellwig To: Kent Overstreet Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:44288 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754207AbaBDSIr (ORCPT ); Tue, 4 Feb 2014 13:08:47 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, Feb 04, 2014 at 09:35:06AM -0800, Kent Overstreet wrote: > > I think Kent is talking about what happens after the user addresses are > > consumed. Turning dio into more of a bio mapping and redirection engine > > would use more of the bio machinery instead of the bits that dio has > > implemented itself with state in struct dio that hangs off the bios. I > > imagine it'd still make sense to clean up the addresses/pages arguments > > that feed that engine. (And give another entry point that already has > > bios for callers like loop, etc.) > > Yeah, precisely. I think we can push the point at which pages are pinned at > least a fair but higher than it is now, and if we can do that we definitely > should be working with a generic "bag of pinned pages" struct - and much > better to use struct bio than add another one. Bios may not be perfect but > at least some of the block layer specific cruft can be gotten rid of (and > is on my todo list) How far up? I've no problem with having that done in ->direct_IO() (especially if it would take this mem_vec/mem_stream/whatever and keep the code doing actual pinning and building an array of pages outside of direct-io.c, allowing it to do different things for iovec-backed and page-array-backed variants), but I really don't like the idea of lifting that to callers of ->direct_IO(), let alone past them. If nothing else, we do *not* want to pin the entire write request, so lifting that to e.g. generic_file_aio_write() (or, worse, its callers) wouldn't make sense.