From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH] add support for vectored and async I/O to all simple filesystems Date: Mon, 7 Nov 2005 06:00:07 +0100 Message-ID: <20051107050007.GA17356@lst.de> References: <20051101023656.GA23724@lst.de> <20051101152710.GA1762@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: hch@lst.de, akpm@osdl.org, linux-fsdevel@vger.kernel.org Return-path: Received: from verein.lst.de ([213.95.11.210]:11232 "EHLO mail.lst.de") by vger.kernel.org with ESMTP id S1751294AbVKGFAN (ORCPT ); Mon, 7 Nov 2005 00:00:13 -0500 To: Miklos Szeredi Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Tue, Nov 01, 2005 at 06:19:22PM +0100, Miklos Szeredi wrote: > > do_sync_read/write are doing the same thing as generic_file_read/write, > > just above the method vectors. Once I have all filesystems support > > proper vectored and aio methods do_sync_read/write will go away > > completly and upper code will always call the complex methods ( > > or hopefull just one cmobined aio/vectored ops with all fancies) > > directly. > > You mean f_op->read, f_op->write going away completely? That's quite > a bit of work yet. No, they will have to stay at least until character drivers get their own set of operation vectors. I just want to make them optional and not need to implement them in all (or at least most) of the filesystems. > Until then you are throwing away some performance in the hottest > read/write paths. Is it worth it? I'm not sure. Did you benchmark > the change? there's not difference in dbench and tiobench runs on ppc64. the only majuor architecture that could support is ia64 because of it's horribly weak branch prediction for indirect calls.