Re: [RFC 1/7] mm: Add new vma flag VM_LOCAL_CPU

From: Miklos Szeredi <mszeredi@redhat.com>
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>
Subject: Re: [RFC 1/7] mm: Add new vma flag VM_LOCAL_CPU
Date: Wed, 14 Mar 2018 16:39:25 +0100	[thread overview]
Message-ID: <CAOssrKdOVp-Yb0A+soPKMH4cDJWAcH8fP2OhCVUW3OjTE9YmqA@mail.gmail.com> (raw)
In-Reply-To: <20180314145719.GH29631@bombadil.infradead.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