qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Emilio G. Cota" <cota@braap.org>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Emilio G. Cota" <cota@braap.org>, qemu-devel@nongnu.org
Subject: [Qemu-devel] [PATCH 0/3] rcu: add option to use upstream liburcu
Date: Tue,  3 Feb 2015 17:08:16 -0500	[thread overview]
Message-ID: <1423001299-11761-1-git-send-email-cota@braap.org> (raw)

Hi Paolo + all,

First off, thanks for your ongoing RCU work, which I'm closely
following.

As you stated in the initial RCU patch (7911747b), the intent
is to keep the same API as liburcu's. I checked whether this
was the case and found a couple of issues that I'm addressing
in the appended series.

* The first two patches bring back the RCU API to exactly
  match that of liburcu.

* The third patch adds a configure flag to choose from either
  liburcu or QEMU's RCU.

Apart from this, I wonder what to do about other valuable bits in
liburcu, particularly in liburcu-cds, which I'm using currently
off-tree.  I see three ways of eventually doing this:

a) Add Windows support in liburcu, thereby eliminating the
   de facto fork in QEMU.

b) Bring (fork) liburcu-cds to QEMU, just like liburcu-mb was.

c) Add a compile-time flag (say CONFIG_LIBURCU_CDS), and then only
   use data structures from liburcu-cds where appropriate, falling
   back to traditional locked structures when !CONFIG_LIBURCU_CDS.

Currently I'm using c) because I cannot do either a) and b)--I
don't know anything about Windows and have no need for it.

Would c) be acceptable for upstream, provided the gains (say in
scalability/memory footprint) are significant?

Thanks,

		Emilio

             reply	other threads:[~2015-02-03 22:07 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-03 22:08 Emilio G. Cota [this message]
2015-02-03 22:08 ` [Qemu-devel] [PATCH 1/3] rcu: use call_rcu semantics from liburcu Emilio G. Cota
2015-02-03 22:08 ` [Qemu-devel] [PATCH 2/3] rcu: use rcu_{dereference, assign_pointer} instead of atomic_rcu_{read, set} Emilio G. Cota
2015-02-04 10:01   ` Paolo Bonzini
2015-02-04 17:25   ` Emilio G. Cota
2015-02-04 17:31     ` Paolo Bonzini
2015-02-03 22:08 ` [Qemu-devel] [PATCH 3/3] rcu: add liburcu knob to configure script Emilio G. Cota
2015-02-04 10:32 ` [Qemu-devel] [PATCH 0/3] rcu: add option to use upstream liburcu Paolo Bonzini
2015-02-04 21:01   ` Emilio G. Cota
2015-02-04 21:17     ` Paolo Bonzini
2015-02-04 23:12       ` Emilio G. Cota

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=1423001299-11761-1-git-send-email-cota@braap.org \
    --to=cota@braap.org \
    --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 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).