All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Emilio G. Cota" <cota@braap.org>
To: qemu-devel@nongnu.org
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
	"Peter Crosthwaite" <crosthwaite.peter@gmail.com>,
	"Richard Henderson" <rth@twiddle.net>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Murilo Opsfelder Araujo" <muriloo@linux.ibm.com>
Subject: [Qemu-devel] [PATCH v2 04/12] qsp: use atomic64 accessors
Date: Mon, 10 Sep 2018 19:27:44 -0400	[thread overview]
Message-ID: <20180910232752.31565-5-cota@braap.org> (raw)
In-Reply-To: <20180910232752.31565-1-cota@braap.org>

With the seqlock, we either have to use atomics to remain
within defined behaviour (and note that 64-bit atomics aren't
always guaranteed to compile, irrespective of __nocheck), or
drop the atomics and be in undefined behaviour territory.

Fix it by dropping the seqlock and using atomic64 accessors.
This will limit scalability when !CONFIG_ATOMIC64, but those
machines (1) don't have many users and (2) are unlikely to
have many cores.

- With CONFIG_ATOMIC64:
$ tests/atomic_add-bench -n 1 -m -p
 Throughput:         13.00 Mops/s

- Forcing !CONFIG_ATOMIC64:
$ tests/atomic_add-bench -n 1 -m -p
 Throughput:         10.89 Mops/s

Signed-off-by: Emilio G. Cota <cota@braap.org>
---
 util/qsp.c | 49 ++++++++-----------------------------------------
 1 file changed, 8 insertions(+), 41 deletions(-)

diff --git a/util/qsp.c b/util/qsp.c
index b0c2575d10..c16af03f6a 100644
--- a/util/qsp.c
+++ b/util/qsp.c
@@ -84,13 +84,6 @@ struct QSPEntry {
     uint64_t n_acqs;
     uint64_t ns;
     unsigned int n_objs; /* count of coalesced objs; only used for reporting */
-#ifndef CONFIG_ATOMIC64
-    /*
-     * If we cannot update the counts atomically, then use a seqlock.
-     * We don't need an associated lock because the updates are thread-local.
-     */
-    QemuSeqLock sequence;
-#endif
 };
 typedef struct QSPEntry QSPEntry;
 
@@ -344,47 +337,16 @@ static QSPEntry *qsp_entry_get(const void *obj, const char *file, int line,
     return qsp_entry_find(&qsp_ht, &orig, hash);
 }
 
-/*
- * @from is in the global hash table; read it atomically if the host
- * supports it, otherwise use the seqlock.
- */
-static void qsp_entry_aggregate(QSPEntry *to, const QSPEntry *from)
-{
-#ifdef CONFIG_ATOMIC64
-    to->ns += atomic_read__nocheck(&from->ns);
-    to->n_acqs += atomic_read__nocheck(&from->n_acqs);
-#else
-    unsigned int version;
-    uint64_t ns, n_acqs;
-
-    do {
-        version = seqlock_read_begin(&from->sequence);
-        ns = atomic_read__nocheck(&from->ns);
-        n_acqs = atomic_read__nocheck(&from->n_acqs);
-    } while (seqlock_read_retry(&from->sequence, version));
-
-    to->ns += ns;
-    to->n_acqs += n_acqs;
-#endif
-}
-
 /*
  * @e is in the global hash table; it is only written to by the current thread,
  * so we write to it atomically (as in "write once") to prevent torn reads.
- * If the host doesn't support u64 atomics, use the seqlock.
  */
 static inline void do_qsp_entry_record(QSPEntry *e, int64_t delta, bool acq)
 {
-#ifndef CONFIG_ATOMIC64
-    seqlock_write_begin(&e->sequence);
-#endif
-    atomic_set__nocheck(&e->ns, e->ns + delta);
+    atomic_set_u64(&e->ns, e->ns + delta);
     if (acq) {
-        atomic_set__nocheck(&e->n_acqs, e->n_acqs + 1);
+        atomic_set_u64(&e->n_acqs, e->n_acqs + 1);
     }
-#ifndef CONFIG_ATOMIC64
-    seqlock_write_end(&e->sequence);
-#endif
 }
 
 static inline void qsp_entry_record(QSPEntry *e, int64_t delta)
@@ -550,7 +512,12 @@ static void qsp_aggregate(struct qht *global_ht, void *p, uint32_t h, void *up)
 
     hash = qsp_entry_no_thread_hash(e);
     agg = qsp_entry_find(ht, e, hash);
-    qsp_entry_aggregate(agg, e);
+    /*
+     * The entry is in the global hash table; read from it atomically (as in
+     * "read once").
+     */
+    agg->ns += atomic_read_u64(&e->ns);
+    agg->n_acqs += atomic_read_u64(&e->n_acqs);
 }
 
 static void qsp_iter_diff(struct qht *orig, void *p, uint32_t hash, void *htp)
-- 
2.17.1

  parent reply	other threads:[~2018-09-10 23:37 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-10 23:27 [Qemu-devel] [PATCH v2 00/12] i386 + x86_64 mttcg Emilio G. Cota
2018-09-10 23:27 ` [Qemu-devel] [PATCH v2 01/12] cacheinfo: add i/d cache_linesize_log Emilio G. Cota
2018-09-11 12:16   ` Richard Henderson
2018-09-11 12:57     ` Paolo Bonzini
2018-09-10 23:27 ` [Qemu-devel] [PATCH v2 02/12] util: add atomic64 Emilio G. Cota
2018-09-11 12:43   ` Richard Henderson
2018-09-11 20:43     ` Emilio G. Cota
2018-09-10 23:27 ` [Qemu-devel] [PATCH v2 03/12] tests: add atomic64-bench Emilio G. Cota
2018-09-10 23:27 ` Emilio G. Cota [this message]
2018-09-10 23:27 ` [Qemu-devel] [PATCH v2 05/12] test-rcu-list: access n_reclaims and n_nodes_removed with atomic64 Emilio G. Cota
2018-09-10 23:27 ` [Qemu-devel] [PATCH v2 06/12] atomic: fix comment s/x64_64/x86_64/ Emilio G. Cota
2018-09-11 12:50   ` Richard Henderson
2018-09-10 23:27 ` [Qemu-devel] [PATCH v2 07/12] cpus: initialize timers_state.vm_clock_lock Emilio G. Cota
2018-09-11 12:50   ` Richard Henderson
2018-09-10 23:27 ` [Qemu-devel] [PATCH v2 08/12] cpus: always call seqlock_write in cpu_update_icount Emilio G. Cota
2018-09-11 12:53   ` Richard Henderson
2018-09-11 12:55     ` Paolo Bonzini
2018-09-10 23:27 ` [Qemu-devel] [PATCH v2 09/12] cpus: access .qemu_icount with atomic64 Emilio G. Cota
2018-09-10 23:27 ` [Qemu-devel] [PATCH v2 10/12] cpus: access .qemu_icount_bias " Emilio G. Cota
2018-09-10 23:27 ` [Qemu-devel] [PATCH v2 11/12] target/i386/translate: use thread-local storage in !user-mode Emilio G. Cota
2018-09-11 12:57   ` Richard Henderson
2018-09-10 23:27 ` [Qemu-devel] [PATCH v2 12/12] configure: enable mttcg for i386 and x86_64 Emilio G. Cota
2018-09-11 12:58   ` Richard Henderson
2018-09-11 13:00 ` [Qemu-devel] [PATCH v2 00/12] i386 + x86_64 mttcg Paolo Bonzini

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=20180910232752.31565-5-cota@braap.org \
    --to=cota@braap.org \
    --cc=alex.bennee@linaro.org \
    --cc=crosthwaite.peter@gmail.com \
    --cc=ehabkost@redhat.com \
    --cc=muriloo@linux.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /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.