All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Anthony Xu <anthony.xu@intel.com>
Cc: Yang Zhong <yang.zhong@intel.com>,
	qemu-devel@nongnu.org, Chao P Peng <chao.p.peng@intel.com>
Subject: Re: [Qemu-devel] [PATCH v1 2/2] reduce qemu's heap Rss size from 12252kB to 2752KB
Date: Sat, 11 Mar 2017 12:04:15 -0500 (EST)	[thread overview]
Message-ID: <920352018.1797331.1489251855464.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <4712D8F4B26E034E80552F30A67BE0B1A0F91A@ORSMSX112.amr.corp.intel.com>


> > Subpages never have subregions, so the loop never runs.  The begin/commit
> > pair then becomes:
> > 
> >     ++memory_region_transaction_depth;
> >     --memory_region_transaction_depth;
> >     if (!memory_region_transaction_depth) {
> >         if (memory_region_update_pending) {
> >             ...
> >         } else if (ioeventfd_update_pending) {
> >             ...
> >         }
> >         // memory_region_clear_pending()
> >         memory_region_update_pending = false;
> >         ioeventfd_update_pending = false;
> >    }
> > 
> > If memory_region_transaction_depth is > 0 the begin/commit pair does
> > nothing.
> > 
> > But if memory_region_transaction_depth is == 0, there should be no update
> > pending because the loop has never run.  So I don't see what your patch can
> > change.
> 
> As I mentioned in PATCH1, this patch is used to fix an issue after we remove
> the global lock in RCU callback. After global lock is removed, other thread
> may set up update pending, so memory_region_transaction_commit
> may try to rebuild PhysPageMap even the loop doesn’t run, other thread may
> try to rebuild PhysPageMap at the same time, it is a race condition.
> subpage MemoryRegion is a specific MemoryRegion, it doesn't belong to any
> address space, it is only used to handle subpage. We may use a new structure
> other than MemoryRegion to handle subpage to make the logic more clearer. After
> the change, RCU callback will not free any MemoryRegion.

This is not true.  Try hot-unplugging a device.

I'm all for reducing the scope of the global QEMU lock, but this needs a plan
and a careful analysis of the involved data structures across _all_ instance_finalize
implementations.

Paolo

  reply	other threads:[~2017-03-11 17:04 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-10 15:14 [Qemu-devel] [PATCH v1 1/2] reduce qemu's heap Rss size from 12252kB to 2752KB Yang Zhong
2017-03-10  8:41 ` Paolo Bonzini
2017-03-10 16:05   ` Xu, Anthony
2017-03-10 16:07     ` Paolo Bonzini
2017-03-10 19:30       ` Xu, Anthony
2017-03-11 17:02         ` Paolo Bonzini
2017-03-10 15:14 ` [Qemu-devel] [PATCH v1 2/2] " Yang Zhong
2017-03-10  9:14   ` Paolo Bonzini
2017-03-10 17:40     ` Xu, Anthony
2017-03-11 17:04       ` Paolo Bonzini [this message]
2017-03-14  5:14         ` Xu, Anthony
2017-03-14 10:14           ` Paolo Bonzini
2017-03-14 21:23             ` Xu, Anthony
2017-03-15  8:36               ` Paolo Bonzini
2017-03-15 19:05                 ` Xu, Anthony
2017-03-15 20:21                   ` Paolo Bonzini
2017-03-16  2:47                     ` Zhong, Yang
2017-03-16 20:02                     ` Xu, Anthony
2017-03-22 11:46                       ` Paolo Bonzini
2017-03-22 18:26                         ` Xu, Anthony

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=920352018.1797331.1489251855464.JavaMail.zimbra@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=anthony.xu@intel.com \
    --cc=chao.p.peng@intel.com \
    --cc=qemu-devel@nongnu.org \
    --cc=yang.zhong@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 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.