From: mathieu.desnoyers@efficios.com (Mathieu Desnoyers)
Subject: [ltt-dev] [URCU RFC patch 3/3] call_rcu: remove delay for wakeup scheme
Date: Mon, 6 Jun 2011 15:21:07 -0400 [thread overview]
Message-ID: <20110606192107.GA25995@Krystal> (raw)
In-Reply-To: <20110606175029.319711589@efficios.com>
* Mathieu Desnoyers (mathieu.desnoyers at efficios.com) wrote:
> I notice that the "poll(NULL, 0, 10);" delay is executed both for the RT
> and non-RT code. So given that my goal is to get the call_rcu thread to
> GC memory as quickly as possible to diminish the overhead of cache
> misses, I decided to try removing this delay for !RT: the call_rcu
> thread then wakes up ASAP when the thread invoking call_rcu wakes it. My
> updates jump to 76349/s (getting there!) ;).
>
> This improvement can be explained by a lower delay between call_rcu and
> execution of its callback, which decrease the amount of cache used, and
> therefore provides better cache locality.
I just wonder if it's worth it: removing this delay from the !RT
call_rcu thread can cause high-rate of synchronize_rcu() calls. So
although there might be an advantage in terms of update rate, it will
likely cause extra cache-line bounces between the call_rcu threads and
the reader threads.
test_urcu_rbtree 7 1 20 -g 1000000
With the delay in the call_rcu thread:
search: 1842857 items/reader thread/s (7 reader threads)
updates: 21066 items/s (1 update thread)
ratio: 87 search/update
Without the delay in the call_rcu thread:
search: 3064285 items/reader thread/s (7 reader threads)
updates: 45096 items/s (1 update thread)
ratio: 68 search/update
So basically, adding the delay doubles the update performance, at the
cost of being 33% slower for reads. My first thought is that if an
application has very frequent updates, then maybe it wants to have fast
updates because the update throughput is then important. If the
application has infrequent updates, then the reads will be fast anyway,
because rare call_rcu invocation will trigger less cache-line bounce
between readers and writers. Any other thoughts on this trade-off and
how to deal with it ?
Thanks,
Mathieu
>
> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>
> ---
> urcu-call-rcu-impl.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> Index: userspace-rcu/urcu-call-rcu-impl.h
> ===================================================================
> --- userspace-rcu.orig/urcu-call-rcu-impl.h
> +++ userspace-rcu/urcu-call-rcu-impl.h
> @@ -242,7 +242,8 @@ static void *call_rcu_thread(void *arg)
> else {
> if (&crdp->cbs.head == _CMM_LOAD_SHARED(crdp->cbs.tail))
> call_rcu_wait(crdp);
> - poll(NULL, 0, 10);
> + else
> + poll(NULL, 0, 10);
> }
> }
> call_rcu_lock(&crdp->mtx);
>
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
next prev parent reply other threads:[~2011-06-06 19:21 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-06 17:45 [ltt-dev] [URCU RFC patch 0/3] call_rcu() performance improvements Mathieu Desnoyers
2011-06-06 17:45 ` [ltt-dev] [URCU RFC patch 1/3] call_rcu: use cpu affinity for per-cpu call_rcu threads Mathieu Desnoyers
2011-06-06 17:45 ` Mathieu Desnoyers
2011-06-06 17:45 ` Mathieu Desnoyers
2011-06-06 19:44 ` Paul E. McKenney
2011-06-06 20:47 ` Mathieu Desnoyers
2011-06-06 21:05 ` Paul E. McKenney
2011-06-06 21:25 ` Mathieu Desnoyers
2011-06-06 17:46 ` [ltt-dev] [URCU RFC patch 2/3] call_rcu: use futex for wakeup scheme Mathieu Desnoyers
2011-06-06 17:46 ` Mathieu Desnoyers
2011-06-06 17:46 ` Mathieu Desnoyers
2011-06-06 20:06 ` [ltt-dev] [rp] " Paul E. McKenney
2011-06-07 4:16 ` Mathieu Desnoyers
2011-06-08 7:04 ` [ltt-dev] " Paolo Bonzini
2011-06-08 22:31 ` Mathieu Desnoyers
[not found] ` <BLU0-SMTP38722641CF9CD185CCFFDC96620@phx.gbl>
2011-06-09 6:14 ` Paolo Bonzini
2011-06-06 17:46 ` [ltt-dev] [URCU RFC patch 3/3] call_rcu: remove delay " Mathieu Desnoyers
2011-06-06 17:46 ` Mathieu Desnoyers
2011-06-06 17:46 ` Mathieu Desnoyers
2011-06-06 19:21 ` Mathieu Desnoyers [this message]
2011-06-06 19:41 ` Paul E. McKenney
2011-06-06 21:29 ` [ltt-dev] [rp] " Phil Howard
2011-06-06 21:39 ` Paul E. McKenney
2011-06-06 22:41 ` Mathieu Desnoyers
2011-06-06 21:26 ` Phil Howard
2011-06-06 22:29 ` Mathieu Desnoyers
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=20110606192107.GA25995@Krystal \
--to=mathieu.desnoyers@efficios.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