Mirror of the lttng-dev mailing list
 help / color / mirror / Atom feed
From: fabiokaminski@gmail.com (Fabio Kaminski)
Subject: [ltt-dev] Running first tests and Stats
Date: Fri, 12 Nov 2010 14:57:44 -0200	[thread overview]
Message-ID: <AANLkTinfGFvPf8akE5pjA33-S+O1TK0NWPNwBn9dn7DW@mail.gmail.com> (raw)
Message-ID: <20101112165744.YNm113sF9Ahx0v9I-MnVSAWGAvEpvpytHOp7loTjAL8@z> (raw)
In-Reply-To: <20101112043343.GA22091@Krystal>

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>


  reply	other threads:[~2010-11-12 16:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-11 21:24 Fabio Kaminski
2010-11-11 21:24 ` Fabio Kaminski
2010-11-11 21:24 ` Fabio Kaminski
2010-11-12  4:33 ` Mathieu Desnoyers
2010-11-12 16:57   ` Fabio Kaminski [this message]
2010-11-12 16:57     ` Fabio Kaminski
2010-11-12 16:57     ` Fabio Kaminski
2010-11-12 19:02     ` Mathieu Desnoyers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AANLkTinfGFvPf8akE5pjA33-S+O1TK0NWPNwBn9dn7DW@mail.gmail.com \
    --to=fabiokaminski@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox