From: Stefan Hajnoczi <stefanha@gmail.com>
To: dan.j.williams@intel.com, qemu-devel@nongnu.org,
Xiao Guangrong <xiaoguangrong.eric@gmail.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Eduardo Habkost <ehabkost@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Igor Mammedov <imammedo@redhat.com>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [RFC PATCH 0/4] nvdimm: enable flush hint address structure
Date: Fri, 7 Apr 2017 15:38:23 +0100 [thread overview]
Message-ID: <20170407143823.GJ16146@stefanha-x1.localdomain> (raw)
In-Reply-To: <20170406103117.7elooodj2k5wrbnu@hz-desktop>
[-- Attachment #1: Type: text/plain, Size: 1478 bytes --]
On Thu, Apr 06, 2017 at 06:31:17PM +0800, Haozhong Zhang wrote:
> On 04/06/17 10:43 +0100, Stefan Hajnoczi wrote:
> > On Fri, Mar 31, 2017 at 04:41:43PM +0800, Haozhong Zhang wrote:
> > We should think about the optimal way of implementing Flush Hint
> > Addresses in QEMU. But if there is no reasonable way to implement them
> > then I think it's better *not* to implement them, just like the Block
> > Window feature which is also not virtualization-friendly. Users who
> > want a block device can use virtio-blk. I don't think NVDIMM Block
> > Window can achieve better performance than virtio-blk under
> > virtualization (although I'm happy to be proven wrong).
> >
> > Some ideas for a faster implementation:
> >
> > 1. Use memory_region_clear_global_locking() to avoid taking the QEMU
> > global mutex. Little synchronization is necessary as long as the
> > NVDIMM device isn't hot unplugged (not yet supported anyway).
> >
>
> ACPI spec does not say it allows or disallows multiple writes to the
> same flush hint address in parallel. If it can, I think we can remove
> the global locking requirement for the MMIO memory region of the flush
> hint address of vNVDIMM.
The Linux code tries to spread the writes but two CPUs can write to the
same address sometimes.
It doesn't matter if two vcpus access the same address because QEMU just
invokes fsync(2). The host kernel has synchronization to make the fsync
safe.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
next prev parent reply other threads:[~2017-04-07 14:38 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-31 8:41 [Qemu-devel] [RFC PATCH 0/4] nvdimm: enable flush hint address structure Haozhong Zhang
2017-03-31 8:41 ` [Qemu-devel] [RFC PATCH 1/4] pc-dimm: add 'reserved-size' to reserve address range after the ending address Haozhong Zhang
2017-04-06 10:24 ` Stefan Hajnoczi
2017-04-06 10:46 ` Haozhong Zhang
2017-04-07 13:46 ` Stefan Hajnoczi
2017-04-11 8:57 ` Haozhong Zhang
2017-04-20 10:54 ` Igor Mammedov
2017-04-06 11:50 ` Xiao Guangrong
2017-03-31 8:41 ` [Qemu-devel] [RFC PATCH 2/4] nvdimm: add functions to initialize and perform flush on back store Haozhong Zhang
2017-04-06 11:52 ` Xiao Guangrong
2017-04-11 8:22 ` Haozhong Zhang
2017-04-11 8:29 ` Haozhong Zhang
2017-04-11 11:55 ` Xiao Guangrong
2017-04-20 13:12 ` Igor Mammedov
2017-03-31 8:41 ` [Qemu-devel] [RFC PATCH 3/4] nvdimm acpi: record the cache line size in AcpiNVDIMMState Haozhong Zhang
2017-03-31 8:41 ` [Qemu-devel] [RFC PATCH 4/4] nvdimm acpi: build flush hint address structure if required Haozhong Zhang
2017-04-06 10:13 ` Stefan Hajnoczi
2017-04-06 10:53 ` Haozhong Zhang
2017-04-07 14:41 ` Stefan Hajnoczi
2017-04-07 15:51 ` Dan Williams
2017-04-06 10:25 ` Stefan Hajnoczi
2017-04-20 11:22 ` Igor Mammedov
2017-04-06 9:39 ` [Qemu-devel] [RFC PATCH 0/4] nvdimm: enable flush hint address structure Xiao Guangrong
2017-04-06 9:58 ` Haozhong Zhang
2017-04-06 11:46 ` Xiao Guangrong
2017-04-06 9:43 ` Stefan Hajnoczi
2017-04-06 10:31 ` Haozhong Zhang
2017-04-07 14:38 ` Stefan Hajnoczi [this message]
2017-04-06 12:02 ` Xiao Guangrong
2017-04-11 8:41 ` Haozhong Zhang
2017-04-11 14:56 ` Dan Williams
2017-04-20 19:49 ` Dan Williams
2017-04-21 13:56 ` Stefan Hajnoczi
2017-04-21 19:14 ` Dan Williams
2017-04-06 14:32 ` Dan Williams
2017-04-07 14:31 ` Stefan Hajnoczi
2017-04-11 6:34 ` Haozhong Zhang
2017-04-18 10:15 ` Stefan Hajnoczi
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=20170407143823.GJ16146@stefanha-x1.localdomain \
--to=stefanha@gmail.com \
--cc=dan.j.williams@intel.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
--cc=xiaoguangrong.eric@gmail.com \
/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).