[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