[ltt-dev] Running first tests and Stats

[ltt-dev] Running first tests and Stats

[Fabio Kaminski]

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..

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?!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20101111/89a19d60/attachment-0003.htm>

[ltt-dev] Running first tests and Stats

[Fabio Kaminski]

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..

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?!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/ltt-dev/attachments/20101111/89a19d60/attachment.htm>

[ltt-dev] Running first tests and Stats

[Fabio Kaminski]

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..

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?!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20101111/89a19d60/attachment-0002.htm>

[ltt-dev] Running first tests and Stats

[Mathieu Desnoyers]

* 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

[ltt-dev] Running first tests and Stats

[Fabio Kaminski]

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>

[ltt-dev] Running first tests and Stats

[Fabio Kaminski]

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>

[ltt-dev] Running first tests and Stats

[Fabio Kaminski]

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>

[ltt-dev] Running first tests and Stats

[Mathieu Desnoyers]

* 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