From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754073AbcAOViH (ORCPT ); Fri, 15 Jan 2016 16:38:07 -0500 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:38022 "EHLO out5-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753719AbcAOViE convert rfc822-to-8bit (ORCPT ); Fri, 15 Jan 2016 16:38:04 -0500 X-Sasl-enc: v3S/ZfEIdQcvd35TxfAE0G1jm1Ymk4qJZPoXs/ihLLGd 1452893882 From: Nikolaus Rath To: Nikhilesh Reddy Cc: Andy Lutomirski , Linus Torvalds , fuse-devel , Al Viro , Greg KH , linux-fsdevel , Linux API , Jan Kara , "Theodore Ts'o" , sven.utcke@gmx.de, Miklos Szeredi , Richard Weinberger , Linux Kernel Mailing List , Antonio SJ Musumeci Subject: Re: [PATCH] fuse: Add support for fuse stacked I/O References: <565394BE.4040506@codeaurora.org> <5696E366.2080605@codeaurora.org> <20160114045716.GB8006@kroah.com> <5697EF97.9020800@codeaurora.org> <871t9i91e1.fsf@thinkpad.rath.org> <56994884.9060002@codeaurora.org> Mail-Copies-To: never Mail-Followup-To: Nikhilesh Reddy , Andy Lutomirski , Linus Torvalds , fuse-devel , Al Viro , Greg KH , linux-fsdevel , Linux API , Jan Kara , Theodore Ts'o , sven.utcke@gmx.de, Miklos Szeredi , Richard Weinberger , Linux Kernel Mailing List , Antonio SJ Musumeci Date: Fri, 15 Jan 2016 13:38:01 -0800 In-Reply-To: <56994884.9060002@codeaurora.org> (Nikhilesh Reddy's message of "Fri, 15 Jan 2016 11:29:08 -0800") Message-ID: <87oacm7ccm.fsf@thinkpad.rath.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Jan 15 2016, Nikhilesh Reddy wrote: > Our local benchmarks on embedded devices (where power and cpu usage is > critical) show that splice doesnt help as much .. when running > multiple cpu's results in increased power usage > > The below results are on a specific device model. > > Where IOPS is number of 4K based read or writes that could be performed each second. > > regular spliced Stacked I/O > sequencial write (MiBPS) 56.55633333 100.34445 141.7096667 > sequencial read (MiBPS) 49.644 60.43434 122.367 > > random write (IOPS) 2554.333333 4053.4545 8572 > random read (IOPS) 977.3333333 1223.34 1432.666667 > > The above tests were performed using a file size of 1GB That looks convincing to me. > Also we can called it FUSE_DELEGATED_IO if that helps :). > I chose to call is stacked i/o since we are technically stacking the > fuse read/writes on the ext4/fat or other filesystems. Yeah, but "stacked" has a pretty strong association with union/overlay file systems (as you have seen), and the feature is not at all specific to that usecase. For example, many FUSE file systems store data in some remote server over the network but cache it on a local disk. The access to the cached data would benefit from the feature under discussion, but I have a hard time thinking of such a FUSE file system being "stacked" on the file system that happens to hold its cache. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«