Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 15 Feb 2021 10:03:54 -0500 (EST)
From:   Mikulas Patocka <mpatocka@redhat.com>
To:     Alexander Viro <viro@zeniv.linux.org.uk>,
        Matthew Wilcox <willy@infradead.org>,
        Zhongwei Cai <sunrise_l@sjtu.edu.cn>,
        Mingkai Dong <mingkaidong@gmail.com>,
        Dan Williams <dan.j.williams@intel.com>,
        Vishal Verma <vishal.l.verma@intel.com>,
        Dave Jiang <dave.jiang@intel.com>
cc:     Andrew Morton <akpm@linux-foundation.org>, Jan Kara <jack@suse.cz>,
        Dave Chinner <david@fromorbit.com>,
        "Theodore Ts'o" <tytso@mit.edu>,
        David Laight <David.Laight@aculab.com>,
        Steven Whitehouse <swhiteho@redhat.com>,
        Eric Sandeen <esandeen@redhat.com>,
        Wang Jianchao <jianchao.wan9@gmail.com>,
        Rajesh Tadakamadla <rajesh.tadakamadla@hpe.com>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        linux-nvdimm <linux-nvdimm@lists.01.org>
Subject: [RFC v3] nvfs: a filesystem for persistent memory
Message-ID: <alpine.LRH.2.02.2102021307370.4109@file01.intranet.prod.int.rdu2.redhat.com>
User-Agent: Alpine 2.02 (LRH 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk

Hi

I announce a new version of NVFS - a filesystem for persistent memory.
        http://people.redhat.com/~mpatocka/nvfs/
        git://leontynka.twibright.com/nvfs.git

Changes since the last release:

I reworked file read/write handling:

* the functions nvfs_read and nvfs_write were deleted beacause it's 
  unlikely that the upstream kernel will allow them.

* the functions nvfs_read_iter and nvfs_write_iter have a fast path if 
  there is just one segment in iov_iter - they will call nvfs_read_locked 
  and nvfs_write_locked directly. This improves performance by 3% on the 
  read path and 1% on the write path.

* read_iter_locked uses copy_to_iter as suggested by Al Viro.

* write_iter_locked doesn't use copy_from_iter_flushcache, because we need 
  copy that doesn't advance the iter (the "copy" and "advance" must be two 
  separate operations). So, I added new operations "iov_iter_map" and 
  "iov_iter_unmap" - iov_iter_map will map the first segment of iov and 
  iov_iter_unmap will unmap it.

Do you think that introducing "iov_iter_map" and "iov_iter_unmap" is 
appropriate? Do you have some other idea how to handle it?

Mikukas