qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: liu ping fan <qemulist@gmail.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Stefan Hajnoczi <stefanha@gmail.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	qemu-devel@nongnu.org, Avi Kivity <avi@redhat.com>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Jan Kiszka <jan.kiszka@siemens.com>
Subject: Re: [Qemu-devel] [PATCH v6 1/8] atomic: introduce atomic operations
Date: Tue, 13 Nov 2012 05:11:53 -0500 (EST)	[thread overview]
Message-ID: <1791134669.9888311.1352801490504.JavaMail.root@redhat.com> (raw)
In-Reply-To: <CAJnKYQnJ=kmDf0uddxe2kT2GrydAhmS4CbyHho5B_EBNhTFqOA@mail.gmail.com>

> > Il 05/11/2012 06:38, Liu Ping Fan ha scritto:
> > > From: Liu Ping Fan <pingfank@linux.vnet.ibm.com>
> > >
> > > If out of global lock, we will be challenged by SMP in low level,
> > > so need atomic ops.
> > >
> > > This file is a wrapper of GCC atomic builtin.
> >
> > I still object to this.
> >
> > I know it enforces type-safety, but it is incomplete.  It doesn't
> 
> Although it is incomplete, but the rest cases are rarely used.  Linux
> faces such issue, and the "int" version is enough, so I think we can
> borrow experience from there.

One of the two places that use __sync_* require 64-bit accesses.  My
RCU prototype required pointer-sized access, which you cannot make type-
safe without C++ templates.

> > provide neither atomic accesses to pointers, nor useful operations such
> > as exchange.  It won't be used consistently, because in some places you
> > just do not have an Atomic value (see both current uses of __sync_*
> > builtins).
> >
> > If you can make it complete, and prove it by using it where
> > __sync_* is
> 
> For current code, __sync_* is used rarely, I think except the
> barriers, only two places use it. We can substitute it easily.

No, you cannot.  See above, one doesn't use ints and the other is
guest state so migration becomes complicated if you use Atomic.  I'm
happy to be proven wrong, however.

Paolo

  parent reply	other threads:[~2012-11-13 10:15 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-05  5:38 [Qemu-devel] [PATCH v6 0/8] push mmio dispatch out of big lock Liu Ping Fan
2012-11-05  5:38 ` [Qemu-devel] [PATCH v6 1/8] atomic: introduce atomic operations Liu Ping Fan
2012-11-12  9:54   ` Paolo Bonzini
2012-11-13  6:48     ` liu ping fan
2012-11-13 10:11       ` Paolo Bonzini
2012-11-14  9:38         ` liu ping fan
2012-11-14  9:47           ` Paolo Bonzini
2012-11-15  7:47             ` liu ping fan
2012-11-15 11:24               ` Paolo Bonzini
2012-11-16  0:03               ` Richard Henderson
2012-11-21  5:58                 ` liu ping fan
2012-11-18 10:04               ` Avi Kivity
2012-11-21  5:57                 ` liu ping fan
2012-11-13 10:11       ` Paolo Bonzini [this message]
2012-11-05  5:38 ` [Qemu-devel] [PATCH v6 2/8] qom: apply atomic on object's refcount Liu Ping Fan
2012-11-05  5:38 ` [Qemu-devel] [PATCH v6 3/8] hotplug: introduce qdev_unplug_complete() to remove device from views Liu Ping Fan
2012-11-12  9:27   ` Paolo Bonzini
2012-11-13  6:12     ` liu ping fan
2012-11-05  5:38 ` [Qemu-devel] [PATCH v6 4/8] pci: remove pci device from mem view when unplug Liu Ping Fan
2012-11-05  5:38 ` [Qemu-devel] [PATCH v6 5/8] memory: introduce local lock for address space Liu Ping Fan
2012-11-05  5:38 ` [Qemu-devel] [PATCH v6 6/8] memory: make mmio dispatch able to be out of biglock Liu Ping Fan
2012-11-05  6:45   ` Jan Kiszka
2012-11-05  5:38 ` [Qemu-devel] [PATCH v6 7/8] memory: introduce tls context to trace nested mmio request issue Liu Ping Fan
2012-11-05  6:57   ` Jan Kiszka
2012-11-05  5:38 ` [Qemu-devel] [PATCH v6 8/8] vcpu: push mmio dispatcher out of big lock Liu Ping Fan
2012-11-05  7:00 ` [Qemu-devel] [PATCH v6 0/8] push mmio dispatch " Jan Kiszka
2012-11-09  6:23   ` liu ping fan
2012-11-09  8:15     ` Jan Kiszka

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=1791134669.9888311.1352801490504.JavaMail.root@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=avi@redhat.com \
    --cc=jan.kiszka@siemens.com \
    --cc=mtosatti@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemulist@gmail.com \
    --cc=stefanha@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).