From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from bombadil.infradead.org ([198.137.202.133]:60832 "EHLO
        bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751402AbeCNO5U (ORCPT
        <rfc822;linux-fsdevel@vger.kernel.org>);
        Wed, 14 Mar 2018 10:57:20 -0400
Date: Wed, 14 Mar 2018 07:57:19 -0700
From: Matthew Wilcox <willy@infradead.org>
To: Miklos Szeredi <mszeredi@redhat.com>
Cc: Boaz Harrosh <boazh@netapp.com>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        Ric Wheeler <rwheeler@redhat.com>,
        Steve French <smfrench@gmail.com>,
        Steven Whitehouse <swhiteho@redhat.com>,
        Jefff moyer <jmoyer@redhat.com>, Sage Weil <sweil@redhat.com>,
        Jan Kara <jack@suse.cz>, Amir Goldstein <amir73il@gmail.com>,
        Andy Rudof <andy.rudoff@intel.com>,
        Anna Schumaker <Anna.Schumaker@netapp.com>,
        Amit Golander <Amit.Golander@netapp.com>,
        Sagi Manole <sagim@netapp.com>,
        Shachar Sharon <Shachar.Sharon@netapp.com>
Subject: Re: [RFC 1/7] mm: Add new vma flag VM_LOCAL_CPU
Message-ID: <20180314145719.GH29631@bombadil.infradead.org>
References: <d5db55b6-e488-986a-81b1-a3514e8eba81@netapp.com>
 <443fea57-f165-6bed-8c8a-0a32f72b9cd2@netapp.com>
 <20180313185658.GB21538@bombadil.infradead.org>
 <CAOssrKfoZKcu1Ku3YOGsoTXmdJeJy71bvQaZ6k3+r6_kD0B2Fg@mail.gmail.com>
 <20180314111750.GA29631@bombadil.infradead.org>
 <CAOssrKdffjmUPpsnzyZudtk9kvT7mXfgMG4fzJvFRQqo5Li79A@mail.gmail.com>
 <20180314114518.GC29631@bombadil.infradead.org>
 <CAOssrKeh7hBfyrkeOekWByYgEp+cjZBoXKz1MSBgC49CtNgf4g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAOssrKeh7hBfyrkeOekWByYgEp+cjZBoXKz1MSBgC49CtNgf4g@mail.gmail.com>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Wed, Mar 14, 2018 at 03:49:35PM +0100, Miklos Szeredi wrote:
> On Wed, Mar 14, 2018 at 12:45 PM, Matthew Wilcox <willy@infradead.org> wrote:
> > Erm ... there's nothing wrong with having one pipe per CPU.  But pipes
> > being non-seekable means that ZUFS can only handle synchronous I/Os.
> > If you want to have a network backend, then you'd only be able to have
> > one outstanding network request per pipe, which is really going to suck
> > for bandwidth.
> 
> I guess ZUFS is mostly about fast synchronous access (please correct
> me if I'm wrong).  Not sure that model fits network filesystems, where
> performance of caching will dominate real life performance.

I'm sure that's Boaz's use case ;-)  But if we're introducing
a replacement for FUSE, let's make it better than FUSE, not just
specialised to Boaz's use case.  Also, networks aren't necessarily slow;
some of us live in a world where the other end-point on the "network"
is *usually* the hypervisor, or a different guest on the same piece of
physical hardware.  Not to mention that 400Gbps ethernet is almost upon
us (standard approved four months ago) and PCIe Gen 4 is only 256Gbps
with a x16 link.