From: fabiokaminski@gmail.com (Fabio Kaminski)
Subject: [ltt-dev] Running first tests and Stats
Date: Fri, 12 Nov 2010 14:57:44 -0200 [thread overview]
Message-ID: <AANLkTinfGFvPf8akE5pjA33-S+O1TK0NWPNwBn9dn7DW@mail.gmail.com> (raw)
In-Reply-To: <20101112043343.GA22091@Krystal>
Sorry about maybe not making myself very clear..
I understand that synchronization tools like mutexes and spinlocks are not
RCU related..
and i found strange too (since it should?nt do many diferrence) , that it
has some diference in the mem IO numbers..
what i meant about "classic implementation", is as i was thinking in linux
kernel scenario.. where spins are the big reality.
thats why i asked.. and since im not doing a proper benchmark.. just
scratching .. i thought someone had tried something like it to share.
thanks anyway.. maybe later i will try debugging, disassembling and
profiling the binary to understand what could be happening.
cheers,
Fabio Kaminski
On Fri, Nov 12, 2010 at 2:33 AM, Mathieu Desnoyers <
compudj at krystal.dyndns.org> wrote:
> * 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 part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20101112/b3072ef9/attachment-0002.htm>
WARNING: multiple messages have this Message-ID
From: fabiokaminski@gmail.com (Fabio Kaminski)
Subject: [ltt-dev] Running first tests and Stats
Date: Fri, 12 Nov 2010 14:57:44 -0200 [thread overview]
Message-ID: <AANLkTinfGFvPf8akE5pjA33-S+O1TK0NWPNwBn9dn7DW@mail.gmail.com> (raw)
Message-ID: <20101112165744.ByW1CWvVAgLG_tBOfZU8MYV6OfSCCo4kJqrXWkOE7zk@z> (raw)
In-Reply-To: <20101112043343.GA22091@Krystal>
Sorry about maybe not making myself very clear..
I understand that synchronization tools like mutexes and spinlocks are not
RCU related..
and i found strange too (since it should?nt do many diferrence) , that it
has some diference in the mem IO numbers..
what i meant about "classic implementation", is as i was thinking in linux
kernel scenario.. where spins are the big reality.
thats why i asked.. and since im not doing a proper benchmark.. just
scratching .. i thought someone had tried something like it to share.
thanks anyway.. maybe later i will try debugging, disassembling and
profiling the binary to understand what could be happening.
cheers,
Fabio Kaminski
On Fri, Nov 12, 2010 at 2:33 AM, Mathieu Desnoyers <
compudj at krystal.dyndns.org> wrote:
> * 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 part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20101112/b3072ef9/attachment-0003.htm>
WARNING: multiple messages have this Message-ID
From: fabiokaminski@gmail.com (Fabio Kaminski)
Subject: [ltt-dev] Running first tests and Stats
Date: Fri, 12 Nov 2010 14:57:44 -0200 [thread overview]
Message-ID: <AANLkTinfGFvPf8akE5pjA33-S+O1TK0NWPNwBn9dn7DW@mail.gmail.com> (raw)
Message-ID: <20101112165744.YNm113sF9Ahx0v9I-MnVSAWGAvEpvpytHOp7loTjAL8@z> (raw)
In-Reply-To: <20101112043343.GA22091@Krystal>
Sorry about maybe not making myself very clear..
I understand that synchronization tools like mutexes and spinlocks are not
RCU related..
and i found strange too (since it should?nt do many diferrence) , that it
has some diference in the mem IO numbers..
what i meant about "classic implementation", is as i was thinking in linux
kernel scenario.. where spins are the big reality.
thats why i asked.. and since im not doing a proper benchmark.. just
scratching .. i thought someone had tried something like it to share.
thanks anyway.. maybe later i will try debugging, disassembling and
profiling the binary to understand what could be happening.
cheers,
Fabio Kaminski
On Fri, Nov 12, 2010 at 2:33 AM, Mathieu Desnoyers <
compudj at krystal.dyndns.org> wrote:
> * 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 part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/ltt-dev/attachments/20101112/b3072ef9/attachment-0001.htm>
next prev parent reply other threads:[~2010-11-12 16:57 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
2010-11-12 16:57 ` Fabio Kaminski [this message]
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=AANLkTinfGFvPf8akE5pjA33-S+O1TK0NWPNwBn9dn7DW@mail.gmail.com \
--to=fabiokaminski@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