* Fabio Kaminski ([email protected]) 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 < > [email protected]> wrote: > > > * Fabio Kaminski ([email protected]) 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 > > > [email protected] > > > 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 _______________________________________________ ltt-dev mailing list [email protected] http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
