qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: peter.maydell@linaro.org, yu.c.zhang@linux.intel.com,
	ehabkost@redhat.com, imammedo@redhat.com, qemu-devel@nongnu.org,
	pbonzini@redhat.com, stefanha@redhat.com,
	crosthwaite.peter@gmail.com, richard.henderson@linaro.org,
	xiaoguangrong.eric@gmail.com
Subject: Re: [Qemu-devel] [PATCH V7 6/6] hostmem-file: add 'sync' option
Date: Wed, 19 Dec 2018 22:42:07 -0500	[thread overview]
Message-ID: <20181219223700-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20181220030312.GA70591@tiger-server>

On Thu, Dec 20, 2018 at 11:03:12AM +0800, Yi Zhang wrote:
> On 2018-12-19 at 10:59:10 -0500, Michael S. Tsirkin wrote:
> > On Wed, Dec 19, 2018 at 05:10:18PM +0800, Yi Zhang wrote:
> > > > > +
> > > > > + - 'sync' option of memory-backend-file is not 'off', and
> > > > > +
> > > > > + - 'share' option of memory-backend-file is 'on'.
> > > > > +
> > > > > + - 'pmem' option of memory-backend-file is 'on'
> > > > > +
> > > > 
> > > > Wait isn't this what pmem was supposed to do?
> > > > Doesn't it mean "persistent memory"?
> > > pmem is a option for memory-backend-file, user should know the backend
> > > is in host persistent memory, with this flags on, while there is a host crash
> > > or a power failures.
> > > 
> > > [1] Qemu will take necessary operations to guarantee the persistence.
> > > https://patchwork.ozlabs.org/cover/944749/ 
> > > 
> > > [2] Host kernel also take opretions to consistent filesystem metadata.
> > > Add MAP_SYNC flags.
> > 
> > OK so I'm a user. Can you educate me please?  
> We suppose an administrator should know it, what is the back-end region coming from,
> is it persistent? what is the font-end device is? a volatile dimm or an
> nonvolatile dimm? then they can choice put the pmem=on[off] and sync=on[off].
> If he didn't, we encourage that don't set these 2 flags.
> 
> > When should MAP_SYNC not
> > be set? Are there any disadvantages (e.g.  performance?)?
> Not only the performance, sometimes like the front-end device is an
> volatile ram, we don't wanna set such option although the backend is a
> novolatile memory, if power lose, all of thing should lose in this ram.



I am not sure how does above answer the questions. If I don't know,
neither will the hypothetical administrator. Looks like a better
interface is needed to make the choice on behalf of the user.


> > 
> > -- 
> > MST
> > 

  reply	other threads:[~2018-12-20  3:42 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-18  8:16 [Qemu-devel] [PATCH V7 0/6] nvdimm: support MAP_SYNC for memory-backend-file Zhang Yi
2018-12-18  8:16 ` [Qemu-devel] [PATCH V7 1/6] numa: Fixed the memory leak of numa error message Zhang Yi
2018-12-18  8:17 ` [Qemu-devel] [PATCH V7 2/6] util/mmap-alloc: switch qemu_ram_mmap() to 'flags' parameter Zhang Yi
2018-12-18 13:35   ` Michael S. Tsirkin
2018-12-18  8:17 ` [Qemu-devel] [PATCH V7 3/6] util/mmap-alloc: support MAP_SYNC in qemu_ram_mmap() Zhang Yi
2018-12-18 13:52   ` Michael S. Tsirkin
2018-12-19  9:25     ` Yi Zhang
2018-12-19 16:42       ` Michael S. Tsirkin
2018-12-18  8:17 ` [Qemu-devel] [PATCH V7 4/6] util/mmap-alloc: Switch the RAM_SYNC flags to OnOffAuto Zhang Yi
2018-12-18  8:17 ` [Qemu-devel] [PATCH V7 5/6] hostmem: add more information in error messages Zhang Yi
2018-12-18  8:17 ` [Qemu-devel] [PATCH V7 6/6] hostmem-file: add 'sync' option Zhang Yi
2018-12-18 14:18   ` Michael S. Tsirkin
2018-12-19  9:10     ` Yi Zhang
2018-12-19 15:59       ` Michael S. Tsirkin
2018-12-20  3:03         ` Yi Zhang
2018-12-20  3:42           ` Michael S. Tsirkin [this message]
2018-12-20  5:37             ` Yi Zhang
2018-12-20 14:06               ` Michael S. Tsirkin
2018-12-21  3:18                 ` Yi Zhang
2018-12-21 16:36                   ` Michael S. Tsirkin
2018-12-24  8:11                     ` Yi Zhang
2019-09-16 15:14                       ` Michael S. Tsirkin
2018-12-18  9:18 ` [Qemu-devel] [PATCH V7 0/6] nvdimm: support MAP_SYNC for memory-backend-file 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=20181219223700-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=crosthwaite.peter@gmail.com \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=stefanha@redhat.com \
    --cc=xiaoguangrong.eric@gmail.com \
    --cc=yu.c.zhang@linux.intel.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).