All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: drjones@redhat.com, lersek@redhat.com, armbru@redhat.com,
	qemu-devel@nongnu.org, famz@redhat.com, lcapitulino@redhat.com
Subject: Re: [Qemu-devel] [PATCH v3 10/12] Dump: add qmp command "query-dump"
Date: Tue, 1 Dec 2015 11:57:57 +0800	[thread overview]
Message-ID: <20151201035755.GI21032@pxdev.xzpeter.org> (raw)
In-Reply-To: <565C478A.8080106@redhat.com>

On Mon, Nov 30, 2015 at 01:56:42PM +0100, Paolo Bonzini wrote:
> 
> 
> On 30/11/2015 12:32, Peter Xu wrote:
> > +{
> > +    DumpQueryResult *result = g_malloc0(sizeof(*result));
> > +    DumpState *state = dump_state_get_global();
> > +    result->status = state->status;
> > +    result->written_bytes = state->written_size;
> 
> You need a mutex around the reads of ->status and ->written_size.

Could I avoid using mutex here? Let me try to explain what I
thought.

The concurrency of this should only happen when:

- detached dump thread is working (dump thread)
- user queries dump status (main thread)

What the dump thread is doing should be something like:

- [start dumping]
- inc written_size
- inc written_size
- ...
- inc written_size
- set ->status to COMPLETED|FAILED
- [end dumping]

Now if the main thread tries to fetch dump status during it's
working, the worst thing is that, the ->written_size fetched by main
thread is not exactly the one when it was fetching ->status. Or say,
we might get some kind of inaccuracy (which should be really small)
without the lock. Meanwhile, we could avoid a lock if we could allow
the very small difference in written_size.

Another thing could happen is when user queries duing it's finishing
(or say, user query between dump thread modify written_size and
status), we might got this:

{ "status": "active", "written": "100", "total": "100" }

Rather than:

{ "status": "completed", "written": "100", "total": "100" }

As long as we make sure we fetch "status" first rather than
"written_size" (that's what I did in current codes). It should still
be acceptable?

Here, the reason I would like to avoid using lock is that: if I use
lock here, I need to use it whenever dump thread increases the
->written_size. That's a operation very frequently happens in dump
thread. I could enhance it though by updating ->written_bytes in
periods, but it might be awkward comparing to directly drop the lock
(if possible) by losing some kind of accuracy.

Not sure whether I missed anything. Also, please let me know if you
still suggest using lock here.

(btw, if using lock, would spinlock be better?)

Thanks!
Peter

> 
> Paolo
> 
> > +    result->total_bytes = state->total_size;
> > +    return result;

  reply	other threads:[~2015-12-01  3:58 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-30 11:32 [Qemu-devel] [PATCH v3 00/12] Add basic "detach" support for dump-guest-memory Peter Xu
2015-11-30 11:32 ` [Qemu-devel] [PATCH v3 01/12] dump-guest-memory: cleanup: removing dump_{error|cleanup}() Peter Xu
2015-11-30 11:32 ` [Qemu-devel] [PATCH v3 02/12] dump-guest-memory: add "detach" flag for QMP/HMP interfaces Peter Xu
2015-11-30 22:05   ` Eric Blake
2015-12-01  2:18     ` Peter Xu
2015-12-01 15:09       ` Paolo Bonzini
2015-12-02  2:31         ` Peter Xu
2015-11-30 11:32 ` [Qemu-devel] [PATCH v3 03/12] dump-guest-memory: using static DumpState, add DumpStatus Peter Xu
2015-11-30 13:00   ` Paolo Bonzini
2015-12-01  2:57     ` Peter Xu
2015-11-30 22:08   ` Eric Blake
2015-12-01  3:04     ` Peter Xu
2015-11-30 11:32 ` [Qemu-devel] [PATCH v3 04/12] dump-guest-memory: add dump_in_progress() helper function Peter Xu
2015-11-30 11:32 ` [Qemu-devel] [PATCH v3 05/12] dump-guest-memory: introduce dump_process() " Peter Xu
2015-11-30 12:55   ` Paolo Bonzini
2015-12-01  3:12     ` Peter Xu
2015-11-30 11:32 ` [Qemu-devel] [PATCH v3 06/12] dump-guest-memory: disable dump when in INMIGRATE state Peter Xu
2015-11-30 11:32 ` [Qemu-devel] [PATCH v3 07/12] dump-guest-memory: add "detach" support Peter Xu
2015-11-30 11:32 ` [Qemu-devel] [PATCH v3 08/12] dump-guest-memory: add qmp event DUMP_COMPLETED Peter Xu
2015-11-30 22:12   ` Eric Blake
2015-12-01  3:27     ` Peter Xu
2015-11-30 11:32 ` [Qemu-devel] [PATCH v3 09/12] DumpState: adding total_size and written_size fields Peter Xu
2015-11-30 11:32 ` [Qemu-devel] [PATCH v3 10/12] Dump: add qmp command "query-dump" Peter Xu
2015-11-30 12:56   ` Paolo Bonzini
2015-12-01  3:57     ` Peter Xu [this message]
2015-12-01  9:54       ` Paolo Bonzini
2015-12-01 12:32         ` Peter Xu
2015-12-01 12:37           ` Paolo Bonzini
2015-12-01 12:45             ` Peter Xu
2015-12-01 12:47               ` Paolo Bonzini
2015-12-01 13:03                 ` Peter Xu
2015-11-30 22:17   ` Eric Blake
2015-12-01  4:40     ` Peter Xu
2015-12-01 13:43       ` Eric Blake
2015-11-30 11:32 ` [Qemu-devel] [PATCH v3 11/12] Dump: add hmp command "info dump" Peter Xu
2015-11-30 11:32 ` [Qemu-devel] [PATCH v3 12/12] Dump: enhance the documentations Peter Xu
2015-11-30 22:22   ` Eric Blake
2015-12-01  4:21     ` Peter Xu

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=20151201035755.GI21032@pxdev.xzpeter.org \
    --to=peterx@redhat.com \
    --cc=armbru@redhat.com \
    --cc=drjones@redhat.com \
    --cc=famz@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=lersek@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.