From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18603 invoked by alias); 23 Sep 2008 03:42:25 -0000 Received: (qmail 18590 invoked by uid 22791); 23 Sep 2008 03:42:24 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from tomts5-srv.bellnexxia.net (HELO tomts5-srv.bellnexxia.net) (209.226.175.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 23 Sep 2008 03:41:43 +0000 Received: from toip3.srvr.bell.ca ([209.226.175.86]) by tomts5-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20080923034137.PUMY1572.tomts5-srv.bellnexxia.net@toip3.srvr.bell.ca> for ; Mon, 22 Sep 2008 23:41:37 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEAPT910hMQWq+/2dsb2JhbACBXbU2gWY Received: from bas5-montreal19-1279355582.dsl.bell.ca (HELO krystal.dyndns.org) ([76.65.106.190]) by toip3.srvr.bell.ca with ESMTP; 22 Sep 2008 23:37:10 -0400 Received: from localhost (localhost [127.0.0.1]) (uid 1000) by krystal.dyndns.org with local; Mon, 22 Sep 2008 23:36:35 -0400 id 00338DA2.48D86443.0000780B Date: Tue, 23 Sep 2008 03:42:00 -0000 From: Mathieu Desnoyers To: Linus Torvalds Cc: Roland Dreier , Masami Hiramatsu , Martin Bligh , Linux Kernel Mailing List , Thomas Gleixner , Steven Rostedt , darren@dvhart.com, "Frank Ch. Eigler" , systemtap-ml Subject: Re: Unified tracing buffer Message-ID: <20080923033635.GK24937@Krystal> References: <33307c790809191433w246c0283l55a57c196664ce77@mail.gmail.com> <48D7F5E8.3000705@redhat.com> <33307c790809221313s3532d851g7239c212bc72fe71@mail.gmail.com> <48D81B5F.2030702@redhat.com> <33307c790809221616h5e7410f5gc37c262d83722111@mail.gmail.com> <48D832B6.3010409@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: X-Editor: vi X-Info: http://krystal.dyndns.org:8080 X-Operating-System: Linux/2.6.21.3-grsec (i686) X-Uptime: 23:31:31 up 110 days, 8:11, 7 users, load average: 0.32, 0.37, 0.39 User-Agent: Mutt/1.5.16 (2007-06-11) X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2008-q3/txt/msg00751.txt.bz2 * Linus Torvalds (torvalds@linux-foundation.org) wrote: > > > On Mon, 22 Sep 2008, Roland Dreier wrote: > > > > Just like Einstein said, it really seems to me that the order of things > > depends on your frame of reference. > > Heh. Yes. In general, there is no single ordering unless you actually use > a serializing lock on all CPU's involved. > > And exactly as in the theory of relativity, two people on different CPU's > can actually validly _disagree_ about the ordering of the same event. > There are things that act as "light-cones" and are borders for what > everybody can agree on, but basically, in the absence of explicit locks, > it is very possible that no such thing as "ordering" may even exist. > > Now, an atomic increment on a single counter obviously does imply *one* > certain ordering, but it really only defines the ordering of that counter > itself. It does not at all necessarily imply any ordering on the events > that go on around the counter in other unrelated cachelines. > > Which is exactly why even a global counter in no way orders "events" in > general, unless those events have something else that does so. > > Linus > Unless I am missing something, in the case we use an atomic operation which implies memory barriers (cmpxchg and atomic_add_return does), one can be sure that all memory operations done before the barrier are completed at the barrier and that all memory ops following the barrier will happen after. Did you have something else in mind ? Mathieu -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68