From mboxrd@z Thu Jan 1 00:00:00 1970 From: compudj@krystal.dyndns.org (Mathieu Desnoyers) Date: Fri, 12 Nov 2010 14:02:51 -0500 Subject: [ltt-dev] Running first tests and Stats In-Reply-To: References: <20101112043343.GA22091@Krystal> Message-ID: <20101112190250.GA1676@Krystal> * 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