linux-s390.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Dan Williams <dan.j.williams@intel.com>,
	Vishal Verma <vishal.l.verma@intel.com>,
	Dave Jiang <dave.jiang@intel.com>,
	Alasdair Kergon <agk@redhat.com>,
	Mike Snitzer <snitzer@redhat.com>,
	Ira Weiny <ira.weiny@intel.com>,
	Heiko Carstens <hca@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Miklos Szeredi <miklos@szeredi.hu>,
	Matthew Wilcox <willy@infradead.org>,
	device-mapper development <dm-devel@redhat.com>,
	Linux NVDIMM <nvdimm@lists.linux.dev>,
	linux-s390 <linux-s390@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	virtualization@lists.linux-foundation.org
Subject: Re: [PATCH 4/5] dax: remove the copy_from_iter and copy_to_iter methods
Date: Tue, 14 Dec 2021 09:22:42 -0500	[thread overview]
Message-ID: <YbiosqZoG8e6rDkj@redhat.com> (raw)
In-Reply-To: <20211213082318.GB21462@lst.de>

On Mon, Dec 13, 2021 at 09:23:18AM +0100, Christoph Hellwig wrote:
> On Sun, Dec 12, 2021 at 06:44:26AM -0800, Dan Williams wrote:
> > On Fri, Dec 10, 2021 at 6:17 AM Vivek Goyal <vgoyal@redhat.com> wrote:
> > > Going forward, I am wondering should virtiofs use flushcache version as
> > > well. What if host filesystem is using DAX and mapping persistent memory
> > > pfn directly into qemu address space. I have never tested that.
> > >
> > > Right now we are relying on applications to do fsync/msync on virtiofs
> > > for data persistence.
> > 
> > This sounds like it would need coordination with a paravirtualized
> > driver that can indicate whether the host side is pmem or not, like
> > the virtio_pmem driver. However, if the guest sends any fsync/msync
> > you would still need to go explicitly cache flush any dirty page
> > because you can't necessarily trust that the guest did that already.
> 
> Do we?  The application can't really know what backend it is on, so
> it sounds like the current virtiofs implementation doesn't really, does it?

Agreed that application does not know what backend it is on. So virtiofs
just offers regular posix API where applications have to do fsync/msync
for data persistence. No support for mmap(MAP_SYNC). We don't offer persistent
memory programming model on virtiofs. That's not the expectation. DAX 
is used only to bypass guest page cache.

With this assumption, I think we might not have to use flushcache version
at all even if shared filesystem is on persistent memory on host. 

- We mmap() host files into qemu address space. So any dax store in virtiofs
  should make corresponding pages dirty in page cache on host and when
  and fsync()/msync() comes later, it should flush all the data to PMEM.

- In case of file extending writes, virtiofs falls back to regular
  FUSE_WRITE path (and not use DAX), and in that case host pmem driver
  should make sure writes are flushed to pmem immediately.

Are there any other path I am missing. If not, looks like we might not
have to use flushcache version in virtiofs at all as long as we are not
offering guest applications user space flushes and MAP_SYNC support.

We still might have to use machine check safe variant though as loads
might generate synchronous machine check. What's not clear to me is
that if this MC safe variant should be used only in case of PMEM or
should it be used in case of non-PMEM as well.

Vivek


  reply	other threads:[~2021-12-14 14:23 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-09  6:38 devirtualize kernel access to DAX Christoph Hellwig
2021-12-09  6:38 ` [PATCH 1/5] uio: remove copy_from_iter_flushcache() and copy_mc_to_iter() Christoph Hellwig
2021-12-12 14:22   ` Dan Williams
2021-12-13  8:27     ` Christoph Hellwig
2021-12-09  6:38 ` [PATCH 2/5] dax: simplify dax_synchronous and set_dax_synchronous Christoph Hellwig
2021-12-09 21:03   ` Pankaj Gupta
2021-12-12 14:23   ` Dan Williams
2021-12-09  6:38 ` [PATCH 3/5] dax: remove the DAXDEV_F_SYNC flag Christoph Hellwig
2021-12-12 14:24   ` Dan Williams
2021-12-13  8:40   ` Pankaj Gupta
2021-12-09  6:38 ` [PATCH 4/5] dax: remove the copy_from_iter and copy_to_iter methods Christoph Hellwig
2021-12-10 14:16   ` Vivek Goyal
2021-12-12 14:44     ` Dan Williams
2021-12-13  8:23       ` Christoph Hellwig
2021-12-14 14:22         ` Vivek Goyal [this message]
2021-12-14 16:41           ` Dan Williams
2021-12-14 20:32             ` Vivek Goyal
2021-12-14 23:43               ` Dan Williams
2021-12-15 15:52                 ` Vivek Goyal
2021-12-15 16:46                   ` Dan Williams
2021-12-15 10:30               ` Stefan Hajnoczi
2021-12-15 15:43                 ` Vivek Goyal
2021-12-15 17:27                   ` Stefan Hajnoczi
2021-12-13 16:17       ` Vivek Goyal
2021-12-12 14:39   ` Dan Williams
2021-12-13  8:24     ` Christoph Hellwig
2021-12-09  6:38 ` [PATCH 5/5] dax: always use _copy_mc_to_iter in dax_copy_to_iter Christoph Hellwig
2021-12-10 14:05   ` Vivek Goyal
2021-12-12 14:48     ` Dan Williams
2021-12-13  8:20       ` Christoph Hellwig
2021-12-13 16:43         ` Dan Williams
2021-12-14 13:59       ` Vivek Goyal
2021-12-12 15:03   ` Dan Williams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YbiosqZoG8e6rDkj@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=agk@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=dm-devel@redhat.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=hch@lst.de \
    --cc=ira.weiny@intel.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=nvdimm@lists.linux.dev \
    --cc=snitzer@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=vishal.l.verma@intel.com \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).