From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from mail-ot0-f181.google.com ([74.125.82.181]:44613 "EHLO
        mail-ot0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751751AbeCNPj0 (ORCPT
        <rfc822;linux-fsdevel@vger.kernel.org>);
        Wed, 14 Mar 2018 11:39:26 -0400
Received: by mail-ot0-f181.google.com with SMTP id 79-v6so3648969oth.11
        for <linux-fsdevel@vger.kernel.org>; Wed, 14 Mar 2018 08:39:26 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <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>
 <20180314145719.GH29631@bombadil.infradead.org>
From: Miklos Szeredi <mszeredi@redhat.com>
Date: Wed, 14 Mar 2018 16:39:25 +0100
Message-ID: <CAOssrKdOVp-Yb0A+soPKMH4cDJWAcH8fP2OhCVUW3OjTE9YmqA@mail.gmail.com>
Subject: Re: [RFC 1/7] mm: Add new vma flag VM_LOCAL_CPU
To: Matthew Wilcox <willy@infradead.org>
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>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Wed, Mar 14, 2018 at 3:57 PM, Matthew Wilcox <willy@infradead.org> wrote:
> 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.

Okay, so the FUSE vs. ZUFS question was bound to be raised at some
point.  What's the high level thinking on this?

We can make ZUFS be a better FUSE, but with a new API?  New API means
we'll lose existing user base.   Having a new API but adding a compat
layer may be able to work around that, but it's probably hard to fully
emulate the old API.

What are the limiting factors in the FUSE API that are preventing
fixing these performance problems in FUSE?

Or it's just that FUSE kernel implementation is a horrid piece of
bloat (true) and we need to do something from scratch without worrying
about backward compat issues?

Is ZUFS planning to acquire a caching layer?

Btw, what is happening when a ZUFS file is mmaped?

Thanks,
Miklos