From: compudj@krystal.dyndns.org (Mathieu Desnoyers)
Subject: [ltt-dev] Running first tests and Stats
Date: Thu, 11 Nov 2010 23:33:44 -0500 [thread overview]
Message-ID: <20101112043343.GA22091@Krystal> (raw)
In-Reply-To: <AANLkTimDZBo9QcDefje+-7-JAHLzpBY9hOW7NZfsHVkm@mail.gmail.com>
* Fabio Kaminski (fabiokaminski at gmail.com) wrote:
> Hi ,
>
> Im playing with Urcu , and first thing was to tried the tests.. and source
> of it..
>
> Read throughtput is very impressive.. really unbeliavable.. :)
>
> so first of all.. thanks for this amazing initiative.. to create this user
> level library!
>
>
> As RCU theoretically mostly uses spinlocks instead of mutexes.. i thought in
> give it a trie..
>
> and changed the test_urcu to use spinlock.. (the same ones provided by
> pthread library) and made a copy..with original mutex lock..
Please note that the mutex used in test_urcu.c is not related to RCU at
all. It simply protects the home-made memory allocation.
In this implementation, the RCU pointer update is done with
"rcu_xchg_pointer()", which atomically exchanges the new pointer with
the old one, so no mutex nor spinlock is needed there (especially if you
don't care about reading the content you are replacing).
Mutexes or spinlocks can be used to protect writes one from another.
Mutexes are typically implemented as adaptative spinlocks turning into
mutexes after a few loops, so there should not be much difference
between the spinlocks and the mutexes you are trying to compare (other
than implementation differences).
> in my own tests.. the writes, with low hits, almost double its values..
> while reads, downgrade just a bit.. (i particularly liked this version :))
>
> so.. my question is if anyone have tried this..
>
> and what are the impressions?!
Impact on read throughput caused by changes in memory allocation locking
scheme is quite unexpected. You might want continue experimenting to
find out why this caused this change in performance.
Thanks,
Mathieu
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
next prev parent reply other threads:[~2010-11-12 4:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-11 21:24 Fabio Kaminski
2010-11-11 21:24 ` Fabio Kaminski
2010-11-11 21:24 ` Fabio Kaminski
2010-11-12 4:33 ` Mathieu Desnoyers [this message]
2010-11-12 16:57 ` Fabio Kaminski
2010-11-12 16:57 ` Fabio Kaminski
2010-11-12 16:57 ` Fabio Kaminski
2010-11-12 19:02 ` 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=20101112043343.GA22091@Krystal \
--to=compudj@krystal.dyndns.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