Mirror of the lttng-dev mailing list
 help / color / mirror / Atom feed
From: mathieu.desnoyers@efficios.com (Mathieu Desnoyers)
Subject: [ltt-dev] [PATCH] fix the "unknown" case
Date: Sun, 13 Jun 2010 17:36:05 -0400	[thread overview]
Message-ID: <20100613213605.GJ5427@Krystal> (raw)
In-Reply-To: <20100613212807.GF2428@linux.vnet.ibm.com>

* Paul E. McKenney (paulmck at linux.vnet.ibm.com) wrote:
> On Sun, Jun 13, 2010 at 05:20:34PM -0400, Mathieu Desnoyers wrote:
> > * Paul E. McKenney (paulmck at linux.vnet.ibm.com) wrote:
> > > On Thu, Jun 10, 2010 at 09:46:31PM -0400, Mathieu Desnoyers wrote:
> > 
> > [...]
> > 
> > (will reply to the rest in the individual patches)
> > 
> > > > Can we trust __sync_lock_test_and_set/__sync_add_and_fetch given that
> > > > __sync_synchronize is broken ?
> > > 
> > > I don't know yet.  If it turns out that we cannot, then I will use some
> > > form of global locking.  But the __sync_lock_test_and_set() do at least
> > > generate instructions, unlike __sync_synchronize().  ;-)
> > 
> > I'm concerned about the fact that their synchronization primitives might have
> > the assembly all with, except for the memory barriers.
> 
> OK.  How about if I used a hashed array of locks, indexed by a hash of
> the cacheline number of the access in question?  Then the "unknown" case
> doesn't depend at all on the __sync_ primitives.

I'm afraid this won't work with signal handlers. :-/ It would be a shame to have
to make these primitives non-signal-safe just for the sake of the "unknown"
arch. Or maybe it could make sense to disable signals around these, even though
it will be really slow ?

Thanks,

Mathieu

> 
> 							Thanx, Paul
> 
> > Thanks,
> > 
> > Mathieu
> > 
> > > 
> > > I will send two patches, one that incorporates your suggestions, and
> > > another that removes sync_core().
> > > 
> > > 							Thanx, Paul
> > > 
> > > > Thanks,
> > > > 
> > > > Mathieu
> > > > 
> > > > > +
> > > > > +#ifdef __cplusplus 
> > > > > +}
> > > > > +#endif
> > > > > +
> > > > > +#include <urcu/uatomic_generic.h>
> > > > > +
> > > > > +#endif /* _URCU_ARCH_UATOMIC_ARMV7_H */
> > > > 
> > > > -- 
> > > > 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

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com




       reply	other threads:[~2010-06-13 21:36 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20100610225242.GA21978@linux.vnet.ibm.com>
     [not found] ` <20100611014631.GA13838@Krystal>
     [not found]   ` <20100611171613.GD2394@linux.vnet.ibm.com>
     [not found]     ` <20100613212033.GF5427@Krystal>
     [not found]       ` <20100613212807.GF2428@linux.vnet.ibm.com>
2010-06-13 21:36         ` Mathieu Desnoyers [this message]
2010-06-14  0:52           ` Paul E. McKenney
2010-06-14  2:08             ` Mathieu Desnoyers
2010-06-14  2:46               ` Mathieu Desnoyers
2010-06-14  5:11                 ` Paul E. McKenney
2010-06-14  5:41                 ` Paul E. McKenney
2010-06-14 17:04         ` Paolo Bonzini
2010-06-14 18:25           ` Paul E. McKenney
2010-06-15  8:52             ` Paolo Bonzini
2010-06-15 14:57               ` Paul E. McKenney
     [not found] <20100614220600.GA15130@linux.vnet.ibm.com>
2010-06-15 12:35 ` Ulrich Weigand
2010-06-15 15:07   ` Paul E. McKenney
2010-06-15 15:18     ` Paolo Bonzini
2010-06-15 16:21       ` Paul E. McKenney
2010-06-15 16:07     ` Ulrich Weigand
2010-06-15 17:00       ` Paul E. McKenney
2010-06-15 17:03         ` Mathieu Desnoyers
2010-06-15 17:32           ` Ulrich Weigand

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=20100613213605.GJ5427@Krystal \
    --to=mathieu.desnoyers@efficios.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