* [ltt-dev] Running first tests and Stats
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
2 siblings, 0 replies; 8+ messages in thread
From: Fabio Kaminski @ 2010-11-12 16:57 UTC (permalink / raw)
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>
^ permalink raw reply [flat|nested] 8+ messages in thread
* [ltt-dev] Running first tests and Stats
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
2 siblings, 0 replies; 8+ messages in thread
From: Fabio Kaminski @ 2010-11-12 16:57 UTC (permalink / raw)
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>
^ permalink raw reply [flat|nested] 8+ messages in thread
* [ltt-dev] Running first tests and Stats
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
2 siblings, 0 replies; 8+ messages in thread
From: Mathieu Desnoyers @ 2010-11-12 19:02 UTC (permalink / raw)
* Fabio Kaminski (fabiokaminski at gmail.com) wrote:
> 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.
It would be simply that by changing the underlying locks used to
synchronize the memory allocation on the write-side, you are increasing
the memory write/sec of the rcu pointer update, which might slow down
reads. Just a thought...
Thanks,
Mathieu
>
> 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
> >
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply [flat|nested] 8+ messages in thread